## 3.1 Plate-formes utilisées

Les plates-formes avec lesquelles le travail s'est réalisé sont d'une part une plate-forme multi-C4x Sundance, et d'autre part deux plate-formes multi-C6x Sundance et Pentek.

### 3.1.1 Plate-forme multi-C4x

Le DSP autour duquel s'articule la plate-forme multi-C4x est le TMS320C4x que nous présenterons d'abord. Ensuite, la plate-forme utilisée intégrant trois de ces DSP sera détaillée.

#### 3.1.1.1 Les TMS320C4x

Les TMS320C4x forment la seconde génération de DSP 32 bits Texas Instruments. Ils sont proposés depuis 1990 et ont évolué jusqu'en 1998. Ils ont été conçus pour des plate-formes multi-processeurs.

Il existe dans le composant des ports de communication spéciaux (Fig. 3.1) constitués chacun de deux FIFO et d'un bloc de décodage d'adresse associé. Chaque DSP possède six ports de communications pouvant assurer chacun un débit de 20 Mocets/sec. Cette logique adaptée permet de relier directement plusieurs DSP de la même famille, le protocole de communication étant identique sur les différents DSP. Ce protocole de communication ainsi que les caractéristiques des liens utilisés forment le standard TIM-40. La notoriété de Texas Instruments a fait que ce standard a été repris par de nombreux développeurs de cartes pour faire communiquer d'autres composants.

<figure><img src="image_46.png" /><figcaption>FIG. 3.1 – Schéma de principe du DSP Texas Instruments TMS320C40</figcaption></figure>

#### 3.1.1.2 Plate-forme Sundance

La partie matérielle se compose de deux modules Texas Instruments, dénotés SMT313 et SMT314, tous les deux intégrés sur une carte mère SMT320 de chez Sundance. Cette carte a été acquise en 1997 par notre laboratoire et utilisée jusqu'en 2001.
La SMT313 correspond à un module de calcul, formé de deux DSP TMS320C44, et la SMT314 à un module pilotant les circuits d'acquisition et de restitution vidéo. Ce dernier possède la particularité, lorsque qu'aucune tâche vidéo ne lui est associée, de pouvoir réaliser des traitements en parallèle avec le module de calcul.

### 3.1.1.3 Description matérielle du module SMT314

Cette carte possède un processeur TMS320C40 pour l'acquisition et l'affichage des images vidéo (Fig. 3.2). Celui-ci possède 4 MOctets de VRAM et est capable de stocker une image entrelacée 2:1 de taille maximum de 1024x512 pixels. La VRAM est connectée à la fois aux entrées et sorties PAL. En ce qui concerne le stockage du programme et des données, 1 MOctets de mémoire SRAM est disponible sur le bus global, et 512 KOctets de SRAM se trouvent sur le bus local. Le processeur est capable d'acquérir un des quatre signaux vidéo d'entrée. Le module dispose également de 4 sorties NTSC/PAL. Ces entrées et sorties sont contrôlées via un lien de communication I2C. Les signaux I2C sont générés par le processeur. Il existe également un port d'interface I2C afin de permettre le contrôle de ces dispositifs. 512 KOctets sont situés sur le bus local, facilitant ainsi le démarrage automatique et les opérations individuelles.

<figure><img src="image_47.png" /><figcaption>FIG. 3.2 – Architecture de la carte SMT314</figcaption></figure>

Une interface JTAG C4x est disponible sur les connecteurs du module TIM, permettant ainsi l'émulation du traitement parallèle avec les modules TIM fournis par les supports de la carte mère. Une simple émulation permet le débogage de n'importe quel module TIM du système.

### 3.1.1.4 Description matérielle du module SMT313

Ce module supporte deux processeurs TMS320C44, et possède une mémoire EDRAM de 8 MOctets découpée de façon égale entre les deux processeurs. L'utilisation de ce type de mémoire apporte une combinaison des avantages d'une SRAM du point de vue rapidité avec la densité d'une DRAM, ce qui permet d'optimiser la bande passante. Chaque processeur possède également 2 MOctets de EDRAM connectés à chacun de ses bus, soit 4
MOctets au total qui peuvent être découpés en différents blocs séparés pour le programme et les données.

La carte intègre également 32 KOctets de EPROM pour le démarrage et le test automatiques. Six ports de communication inter-processeur ont un débit de 20 MOctets/sec chacun.

<figure><img src="image_48.png" /><figcaption>FIG. 3.3 – Architecture de la carte SMT313</figcaption></figure>

Des communications déjà existantes sur la carte mère servent aux transferts entre les modules TIM (Texas Instruments Module). En plus de ceux-ci, nous avons rajouté des communications au moyen de câbles de communications.

Le processeur que nous appelons *root* correspond au DSP de la carte vidéo (SMT314). Les deux autres, P1 et P2, correspondent aux deux DSP de la carte de traitement (SMT313). Une connexion par l'intermédiaire d'un câble a été rajoutée entre le processeur P2 (L1) et le root (L4), les deux autres étant imposées par la carte mère. La figure 3.4 montre le graphe matériel SynDEx modélisant la topologie globale de cette plate-forme sous la version 4. Celle-ci a été utilisée, malgré l'existence de la version 5, car elle seule possédait un noyau pour DSP C40.

<figure><img src="image_49.png" /><figcaption>FIG. 3.4 – Graphe matériel SynDEx V4 pour la plate-forme multi-C4x</figcaption></figure>
### 3.1.2 Plate-forme multi-C6x

L'architecture relativement simple et les faibles fréquences horloge des TMS320C4x font que cette famille de DSP n'est plus utilisée pour les grosses applications, au profit des TMS320C6x. Dans un premier temps, nous allons présenter cette famille de processeurs et leurs possibilités de mise en parallèle, puis ensuite nous développerons les plate-formes Sundance et Pentek.

#### 3.1.2.1 Les TMS320C6X

Les solutions mises en œuvre pour les DSP Texas Instruments C6x sont particulièrement révélatrices des évolutions actuelles pour ce type de processeurs. Ces DSP sont dotés d'horloges allant de 150 MHz à 600 MHz, et du VelociTI, une architecture VLIW (Very-Long-Instruction-Word) hautement performante et très avancée (Fig. 3.5).

<figure><img src="image_50.png" /><figcaption>FIG. 3.5 – architecture d'un C6x.</figcaption></figure>

Le CPU comporte deux chemins de données incluant chacun un registre global, découpé en seize registres indépendants de 32 bits reliés deux par deux aux quatre unités fonctionnelles (L1, S1, M1, D1, et L2, S2, M2 et D2, Fig. 3.5). Le CPU est donc capable d'exécuter jusqu'à huit instructions de 32 bits sur huit unités de calcul par cycle d'horloge. Les huit unités de calcul correspondent à deux multiplieurs et six unités arithmétiques et logiques supportant des opérations au format fixe (séries 62x et 64x) ou flottant (série 67x).

Les C6x ont des architectures Harvard et possèdent deux mémoires internes, une pour les données et une pour le programme. Les tailles de ces mémoires varient en fonction des C6x: par exemple, le C6201 utilisé par la suite possède des mémoires de 512 KOctets. Il
est possible d'ajouter des mémoires externes connectées par les bus d'entrée/sortie, qui permettent de développer des programmes plus importants et de manipuler des ressources plus lourdes, au détriment de la rapidité.

Des études [HU99] ont été menées pour quantifier le gain entre l'utilisation des mémoires internes et externes des C6x pour les TMS320C6x. Les mémoires internes sont de type RAM pour le programme et les données, et donnent accès à huit instructions et à trois données de 32 bits par temps de cycle. Les deux bus accédant aux données peuvent réaliser une lecture et une écriture dans le même temps de cycle. D'autre part, les mémoires externes peuvent être de types RAM, SRAM (Static RAM), SBSRAM (Synchronous Burst SRAM) ou SDRAM (Synchronous Dynamic RAM). La technologie SRAM offre les mémoires les plus petites, mais les plus rapides. L'interface est relativement simple (soit une lecture, soit une écriture à la fois) et asynchrone. Les mémoires synchrones (SBSRAM et SDRAM) proposent une interface plus complexe: un unique accès est plus long que pour une SRAM, mais après ce premier accès, les suivants sont plus rapides si ils restent dans le même mode (lecture ou écriture). De plus, les mémoires SDRAM peuvent fonctionner de deux manières: "page hit", où la mémoire est divisée en pages qu'il faut ouvrir avant un accès, ce qui est relativement long pour le premier accès à une page donnée, ou "page miss", où la mémoire n'a pas ce découpage en pages. Il en résulte des variations importantes dans les temps de calcul.

Des tests sur des opérations intensives de FFT et de convolutions, exploitant au maximum le parallélisme du VLIW, ont été réalisés. La figure 3.6 présente les résultats obtenus et montre que les gains de temps sont importants lorsque la mémoire interne est utilisée pour positionner le programme (histogrammes de gauche) et les données (histogrammes de droite). Le rapport d'accélération peut atteindre la valeur de 16 lorsque les opérations utilisent un maximum le parallélisme de l'architecture (opération de FFT) et dans un rapport moindre lorsque le parallélisme du VLIW est moins utilisé (opérations de convolution). Les fonctions de tests sont relativement petites et peuvent être placées totalement dans une mémoire cache située entre les mémoires externes et le DSP. Cette possibilité donne un accès rapide aux mémoires externes et la différence de performances entre l'utilisation des mémoires internes et des mémoires externes devient négligeable comme le montrent les histogrammes centraux de la figure 3.6.

<figure><img src="image_51.png" /><figcaption>FIG. 3.6 – Comparaison des temps de calcul de FFT et de convolutions en fonction des mémoires utilisées sur un C6x.</figcaption></figure>
Le DMA possède quatre canaux programmables : quatre communications peuvent donc être gérées simultanément. Les tests réalisés par [HU99] et présentés figure 3.6 n'utilisent pas cette possibilité qui améliorerait pourtant la rapidité des transferts.

La développement logiciel sur DSP peut se faire avec plusieurs langages : C, C++ ou assembleur. L'assembleur permet de décrire les instructions pour chacune des huit unités de calcul du CPU. L'utilisation du parallélisme de l'architecture peut alors être optimale, mais les temps de développement sont très importants et nécessitent une connaissance spécifique de chaque C6x à programmer.

Code composer Studio est un compilateur conçu exclusivement pour les C6x et développé par Texas Instrument. Son optimisateur permet de trouver sur d'un programme écrit en langage C conventionnelles les opérations pouvant être réalisées en parallèle par le CPU. Un "pipelinage" (séquencement optimal des instructions) est utilisé pour atteindre des hautes performances. Les optimisations nécessitent un développement particulier, reposant souvent sur l'expérience du concepteur. Un programme en C peut être implanté de manière très efficace si l'on observe quelques règles de base pour une conception de qualité :

- optimisation des options de compilation selon les contraintes retenues (taille du code généré, rapidité de traitement),

- utilisation d'un format adéquat selon les données traitées (flottant et fixe sur 32 bits, court sur 16 bits, caractère sur 8 bits),

- utilisation des instructions spécifiques au composant,

- concatenation des données au sein d'un même registre pour augmenter le parallélisme de traitement.

- placement des données (variables et programme) dans les différentes zones mémoires du composant lors de l'édition de lien.

### 3.1.2.2 Les différentes familles de C6x

#### TMS320C62x

Ce sont les premiers C6x sortis par Texas Instruments en 1998. Avec des fréquences allant de 150 à 300 MHz, ils ont été les premiers DSP à architecture VLIW.

#### TMS320C67x

Ce sont les DSP virgule flottante de la gamme. Les données sont de 64 bits, et les bus internes également. Les fréquences proposées vont de 100 à 225 MHz. Le jeu d'instructions est identique à celui du C62x, auquel ont été ajoutées des instructions pour les calculs spécifiques en virgules flottantes. Actuellement, aucune nouvelle version n'est annoncée.

#### TMS320C64x

Ce sont les derniers DSP de la gamme proposés par Texas Instruments. Comme les C62x, ce sont des DSP 16 bits virgule fixe. L'avantage de cette famille est qu'elle bénéficie des progrès technologiques et peut atteindre des fréquences allant de 300 à 600 MHz. Des efforts ont également été réalisés pour les transferts de données dans le processeur avec des bus 64 bits. Le jeu d'instructions a été étoffé par rapport à celui du C62x avec des instructions SIMD (single-instruction multiple-data) pour pouvoir traiter plusieurs données avec une unique instruction et ainsi diminuer la taille du programme. Ces instructions ont été
spécialement ajoutées pour les applications de traitement des images et pour l'utilisation du bus interne 64 bits.

Le jeu d'instruction du C62x ayant été repris dans tous C64x et C67x, tous les programmes conçus et optimisés pour les C62x, en particulier les bibliothèques fournies par Texas Instruments, peuvent être utilisés directement sur tous les C6x. Par contre, l'inverse n'étant pas vrai, l'offre en termes de bibliothèque reste plus faible pour les C62x.

### 3.1.2.3 Les C6x et le parallélisme

Comme nous l'avons vu précédemment (Part. 3.1.1.1), les C4x intègrent des ports de communications appelés CP et fournissant des communications directes inter-C4x. Cette interface spécifique permet de construire rapidement des architectures parallèles. Les C6x ne possèdent pas de CP, c'est pourquoi les fabricants de cartes multi-C6x doivent ajouter des ressources matérielles entre les C6x afin de rendre possible les communications (fig.3.7), devenant de ce fait dépendantes de l'architecture. L'assemblée spécifique au noyau d'exécutif C4x n'est plus utilisable sur le C6x.

<figure><img src="image_52.png" /><figcaption>FIG. 3.7 – C6x Logique additionnelle pour les communications</figcaption></figure>

La logique additionnelle généralement adoptée par les fabricants est une FIFO connectée au premier DSP, et qui communique via une autre FIFO connectée à l'autre DSP. La taille, les informations de contrôle et d'état de la FIFO peuvent changer suivant la plate-forme. Une FIFO peut interrompre ou non une séquence de calcul sur le DSP par exemple à la fin d'un transfert. Le nombre et la manière de générer ces interruptions peuvent changer et ces spécifications sont effectuées par les fabricants.

### 3.1.2.4 Plate-forme Sundance multi-C6x

Comme pour la plate-forme multi-C4x, la plate-forme multi-C6x est constituée d'une carte mère SMT320 possédant deux modules Texas Instrument (TIM) SMT335. La carte
<figure><img src="image_53.png" /><figcaption>FIG. 3.8 – Présentation de la carte smt335</figcaption></figure>

a été acquise par notre laboratoire en mai 2001. Chaque module SMT335 est constitué d'un DSP Texas Instruments TMS320C6201 de fréquence d'horloge à 200 MHz (Fig. 3.8).

Un FPGA sur chaque module gère six ports de communications 20 MB/s similaires aux bus inter-C4x présentés précédemment (Part. 3.1.1.1). De plus, le FPGA met en place le protocole de communication pour deux bus SDB (Sundance Digital Bus).

Les six ports de communication sont connectés directement sur la carte mère SMT320. Ces six liens sont numérotés de 0 à 5. Chaque lien peut être un émetteur ou un récepteur, et automatiquement basculer d'un état à l'autre. A l'initialisation, les trois premiers liens sont définis comme des émetteurs et les trois suivants comme des récepteurs, sachant qu'il est impossible de relier deux émetteurs et deux récepteurs ensemble, la seule solution est d'avoir au moins un émetteur et un récepteur sur une liaison. Chaque CP est associé avec 2 FIFO unidirectionnelles de 16*32 bits, l'une en entrée et l'autre en sortie.

Les SDB, bus propriétaires de Sundance, sont eux connectés directement sur le module SMT335 et peuvent supporter des taux de transfert de 200 MOctets par seconde pour des mots de 32 bits (400 Mo pour des mots de 16 bits). Un SDB intègre 2 FIFO unidirectionnelles de 256*32 bits, une en entrée et une en sortie. Une fois les 2 SDB connectés (un sur chaque module), l'un des deux doit être configuré comme un émetteur, l'autre en récepteur.

L'ensemble de ces bus permet les transferts de données entre les unités de calcul de la plate-forme. Ces forts débits sont indispensables aux transferts rapides des images et données de taille importante rencontrées dans le codage vidéo, comme nous avons pu l'observer lors des implantations multi-C4x.

Des mémoires externes sont connectées aux DSP : 16 MOctets de mémoire SDRAM et 512 KOctets de mémoire SBSRAM. Ces mémoires additionnelles autorisent l'implantation de programmes et de données beaucoup plus conséquents que sur la plate-forme multi-C4x.

Quant aux données, l'utilisation de la SBSRAM est 15 fois plus lente que celle de la mémoire interne, et la SDRAM 20 fois plus lente.

Contrairement à la plate-forme multi-C4x, nous avons deux C6201 disponibles pour effectuer les calculs mais pas de système d'acquisition/restitution. Il est toutefois possible d'ajouter une telle carte fille, mais cette dernière n'était pas disponible jusqu'alors.

### 3.1.2.5 Plate-forme Pentek multi-C6x

L'architecture Pentek n'est pas modulaire comme précédemment : elle comporte une seule carte appelée par la suite plate-forme. Cette carte est la propriété de Mitsubishi ITE
<figure><img src="image_54.png" /><figcaption>FIG. 3.9 – *Description de la plate-forme Sundance sous SynDEx V5.2*</figcaption></figure>

Rennes, et a été à notre disposition afin de réaliser le noyau SynDEx pour C6x que nous présenterons dans la partie suivante.

<figure><img src="image_55.png" /><figcaption>FIG. 3.10 – *Environnement matériel*</figcaption></figure>

La plate-forme contient 4 DSP TMS320C6201 à 200MHz, et est incluse dans une chaîne de traitement numérique (Fig. 3.10). Chaque processeur dispose de différentes ressources mémoires: 16 Mo de SDRAM, 512 kilo-octets de SBSRAM et 256 kilo-octets de dual port RAM. Chaque processeur est également équipé de différentes ressources d'entrée/sortie: 1 FIFO inter-processeur bidirectionnelle de 2\*1k\*32 bits et 1 FIFO bidirectionnelle de 2\*1k\*32 bits pour une carte mezzanine d'E/S.

Les taux de transfert pour les différentes ressources sont :

- SDRAM à 400Mo/s.

- SBSRAM à 800Mo/s.

- BI-FIFO (Mezzanine, inter-processeurs) à 400Mo/s.
Cette plate-forme contient également des ressources accessibles par les quatre processeurs :

- 4 dual-ports SRAM de 256 kilo-octets.

- 8 kilo-octets de SRAM non volatile.

- 8 Mo de mémoire flash.

- 8 Mo de SRAM globale.

Nous dirons par la suite que les FIFO (inter-processeur ou d'entrée/sortie) reliées à chaque processeur sont de type BIFO.

<figure><img src="image_56.png" /><figcaption>FIG. 3.11 – Description de la plate-forme Pentek sous SynDEx V5.2</figcaption></figure>

## 3.2 Noyaux d'exécutifs génériques synchronisés

Un des objectifs de cette thèse a été d'utiliser la méthodologie AVS/SYNDEX sur des plates-formes multi-C6x et pouvoir ainsi bénéficier d'une puissance de calcul de premier ordre. Dans cette optique, il a fallu s'intéresser à la création automatique de code à partir de SynDEX et son adaptation aux plates-formes visées.

Ce travail a été développé parallèlement lors d'un stage de trois mois par Mickael Raulet et Yann Le Mener, sous ma responsabilité et en collaboration avec Mitsubishi ITE Rennes [MR01, MRN+02]. Ma participation dans ce développement se situe dans le travail de spécification, d'encadrement et de validation du noyau créé.

Tout d'abord, la présentation des principes des exécutifs synchronisés permettra de situer le contexte du développement par rapport aux travaux de recherche menés sur SynDEX à l'INRIA. Ensuite, nous justifierons les choix effectués pour le développement d'un noyau d'exécutif pour Texas Instruments C6x. Enfin, les développements réalisés seront détaillés.

### 3.2.1 Principes des exécutifs synchronisés

Cette partie sur les exécutifs synchronisés va permettre de situer le travail réalisé par rapport aux recherches effectuées à l'INRIA. Pour tout détail complémentaire sur la construction des graphes, ainsi que pour leur fonctionnement, il faut se reporter au document [Gra00], spécialement dans sa seconde partie.
La figure 3.12 récapitule l'ensemble des opérations réalisées entre la description des graphes sous SynDEx et l'implantation mono ou multiprocesseur. Un nouveau graphe (graphe d'implantation, Fig. 3.12) est construit à partir du graphe d'algorithme et du graphe d'architecture lors de la phase d'adéquation. Pour cela, SynDEx utilise une heu-ristique d'optimisation fondée sur la prédiction de performances.

Après avoir construit le graphe d'implantation optimisé, des règles sont mises en œuvres pour générer automatiquement le programme optimisé de chaque processeur de l'architec-ture. Chaque programme est constitué d'une partie applicative qui correspond à l'algorithme, et d'une autre partie appelée exécutif qui gère les ressources matérielles. SynDEx génère un macro exécutif générique, indépendant de la cible. En-suite, le macro processeur M4 permet de transformer le macro exécutif générique en un exécutif compilable pour la cible. Cet exécutif est finalement compilé par l'outil relatif à la cible (code composer pour des DSP Texas Instruments).

La partie applicative dans notre approche AVS/SynDEx est directement constituée des fonctions réalisées sous AVS. Ces fonctions sont écrites en langage C et constituent les bibliothèques spécifiques à l'algorithme de la figure 3.12. Nous intéressons donc ici à la génération de l'exécutif.

La génération automatique d'exécutifs distribués permet de passer du graphe d'im-plantation jusqu'au téléchargement des fichiers binaires pour chacun des processeurs. Nous allons rappeler brièvement les principes des différentes étapes permettant cette transfor-mation.

### 3.2.1.1 Modèle de macro-exécutif générique

Tout d'abord, un ensemble de transformations sur le **graphe d'implantation** opti-misé permet de construire un réseau de Pétri qui modélise le comportement des différents processeurs.

A la spécification de l'algorithme qui constitue la partie itérative (séquence de calcul) du programme final, doivent être ajoutés des phases d'initialisation et de finalisation. Un ensemble de synchronisations doit être ajouté à ce réseau pour assurer le bon fonctionne-ment dans l'exécution de ces phases sur chacun des processeurs.

La figure 3.13 nous montre un exemple d'un réseau de Pétri synchronisé devant être implanté sur un processeur. Sur ce dernier apparaît deux séquenceurs. Le premier, **le séquenceur de calcul**, réalise les opérations de calcul de l'algorithme, et le second, **le séquenceur de communication** (à droite), prend en charge les communications. Pour chacun d'eux, on peut noter que la partie située entre "Loop" et "EndLoop" constitue la partie itérative, succédant à la phase d'initialisation et précédent la phase de finalisation. A l'intérieur de la partie itérative, la séquence de calcul génère des données (producteur) devant être envoyés par la séquence de communication (consommateur). La production de donnée devant être exécutée avant sa consommation, un sémaphore ("Pre - full" et "Suc - full" sur la figure) réalise cette synchronisation dite intra-itération. Tant que l'envois de la donnée n'est pas terminée par la séquence de communication, la séquence de calcul ne doit pas débuter un nouveau calcul producteur. C'est la raison pour laquelle un nouveau sémaphore ("Pre - empty" et "Suc - empty") doit être implanté. On parle alors de synchronisation inter-itération.

Un exemple de réseau de Pétri complet pour une application portée sur deux proces-
<figure><img src="image_57.png" /><figcaption>FIG. 3.12 – opérations réalisées par SynDEx</figcaption></figure>
<figure><img src="image_58.png" /><figcaption>FIG. 3.13 – Réseaux de Pétri synchronisés pour deux processeurs</figcaption></figure>
seurs est fourni figure 3.14. Ce graphe correspond au **graphe d'exécution** de la figure 3.12.

La figure 3.14 fait apparaître quatre "sous-réseaux" pour une adéquation réalisée à partir d'un graphe d'architecture à deux processeurs. Les deux réseaux "OPR1" et "C1" sont réalisés sur un processeur, et "C2" et "OPR2" sur le second. "C1" et "C2" permettent un transfert de données entre les deux séquenceurs de communication sur chacun des processeurs. "OPR1" et "OPR2" concernent les calculs du graphe d'algorithmes synchronisés, ce sont des séquences de calcul. Les séquences de communications étant synchronisées entre elles et avec les séquences de calcul de leur processeur respectif, les séquences de calcul sur les différents processeurs sont alors bien synchronisés.

Le modèle d'exécutif ainsi créé est bien entendu générique, et assure l'ordre d'exécution des calculs et des transferts de données sans interblocage, quelques soient les temps d'exécution effectifs.

### 3.2.1.2 Macro-code généré par SynDEx

Le modèle d'exécutif que nous venons de rappeler est ensuite traduit est un macro-code générique plutôt que de le transformer directement en fichiers compilables pour un processeur donné. Ce macro-exécutif générique (Fig. 3.12) devra ensuite être transformé en fichiers sources compilables à l'aide du noyau d'exécutif adapté à la source visée. Cette étape est essentielle pour assurer l'indépendance maximale du processus vis-à-vis du matériel.

Pour chaque processeur, le macro-code générique comprend dans l'ordre :

- l'inclusion de la bibliothèque Syndex.m4x,

- une macro "processor" prenant en argument le type et le nom du processeur ainsi que le nom de l'application,

- les macros d'allocation mémoire,

- les macros de chaque séquence de communication (une par média de communication disponible sur le processeur),

- les macros de la séquence de calcul (appels ordonnés des fonctions),

- les macros de synchronisation,

- une macro "endprocessor" sans argument,

Il faut ensuite transformer ces programmes, avec le macro-processeur M4, pour qu'ils soient compilables puis exécutables par le processeur choisi.

### 3.2.1.3 Le macro-processeur M4

Le processus qui conduit à l'objectif final de la méthodologie AAA (l'exécution de l'algorithme sur l'architecture réelle) inclut tout d'abord la transformation de chaque macro-exécutif, constituant les programmes de chaque processeur, en un exécutif compilable.

Un macro-processeur [LO96] est un programme qui consomme en entrée une chaîne de caractères (texte source), la traite séquentiellement en substituant chaque sous-chaîne qu'il reconnaît ("appel de macro") par une chaîne correspondante de substitution ("définition de macro"). Celle-ci est traitée à nouveau jusqu'à ce qu'il n'y ait plus de substitution possible.
<figure><img src="image_59.png" /><figcaption>FIG. 3.14 – Exemple de réseau de Pétri d'un graphe d'exécution reparti sur deux processeurs possédant chacun une séquence de calcul (OPRi) de communication (Ci)</figcaption></figure>
Dans un macro-processeur il y a un dictionnaire de "macros" qui associe chaque nom de macro à reconnaître avec une définition. Un appel de macro peut comprendre, juste après le nom de la macro, une liste de sous-chaînes arguments qui est substituée aux paramètres formels trouvés dans la définition de la macro. Un certain nombre de macros est prédéfini au démarrage du macro-processeur dont au moins une qui permet de définir de nouvelles macros. Le macro-processeur GNU m4 a été choisi par l'INRIA Rocquencourt pour d'autres noyaux SynDEx car il est libre, simple mais suffisamment puissant et standard (sur les systèmes d'exploitation Unix).

Les définitions des macros sont contenues dans des bibliothèques. Pour faciliter le portage d'un noyau d'exécutif sur différentes architectures et réutiliser le plus de définitions possible, le noyau est partagé en plusieurs parties (i.e. plusieurs bibliothèques de macros). Ces bibliothèques se décomposent en deux grandes familles (Fig. 3.15), les noyaux génériques (indépendants de l'application) et les noyaux non génériques (spécifiques à l'application). Ensuite, on distingue les noyaux génériques indépendants (Syndex.m4x) et dépendants de l'architecture, puis, dans les noyaux spécifiques à l'architecture, les bibliothèques contenant les macros spécifiques au type de processeur, au processeur et au type de communication.

<figure><img src="image_60.png" /><figcaption>FIG. 3.15 – Organisation du noyau d'exécutif</figcaption></figure>

### 3.2.2 Méthode utilisée

L'objectif pour nous a donc été la création d'un noyau pour DSP TMS320C6x permettant de traduire les macro-codes génériques créés par SynDEx suite à l'adéquation, en un exécutif compilable pour les C6x. Ainsi, toutes les applications décrites sous SynDEx pourront être portées automatiquement sur des architectures multi-C6x.

Puisque le macro-code générique doit être transformé en un code compilable, les techniques de programmation vont influer sur les performances finales. Nous allons maintenant justifier les choix fixés dès le début des développement.
### 3.2.2.1 Utilisation du DMA

L'objectif est de pouvoir implanter un réseau comme présenté figure 3.13 sur un processeur. Physiquement, un processeur possède un unique séquenceur appelé CPU. Les deux séquences (calcul et communication) devraient alors être exécutées par le CPU, interdisant tout parallélisme réel entre ces deux séquences. Il est cependant possible d'utiliser le DMA du C6x qui va pouvoir prendre en charge une partie des communications.

<figure><img src="image_61.png" /><figcaption>FIG. 3.16 – parallélisme entre calcul et communication.</figcaption></figure>

Le DMA doit être programmé par le CPU pour une communication donnée. Ensuite, il peut être vu comme un co-processeur qui va gérer l'envois ou la reception des données sur le système physique de communication. Il en résulte que la séquence de calcul sera réalisée entièrement par le CPU et que la séquence de communication sera partagée entre le CPU et le DMA, comme le montre la figure 3.16. En conséquence, une exécution des séquences de calcul et de communication totalement parallèle comme spécifié dans le modèle SynDEx n'est pas strictement réalisable.

### 3.2.2.2 Indépendance vis-à-vis des RTOS

Les développements sur plate-formes multi-C6x reposent souvent sur l'utilisation de RTOS, et dans notre cas le 3L de Diamond. Il est alors possible d'utiliser des primitives de communication inter-C6x, ainsi que des mécanismes de synchronisation. Cette solution est particulièrement simple à mettre en œuvre puisqu'il faut uniquement remplacer le macro-code générique en un appel à ces primitives.

En revanche, cela implique le chargement sur les cible de l'ensemble du noyau temps-réel. Le coût spatial et temporel que cela engendre est important, et ce pour une utilisation très restreinte des possibilités du noyau. Le RTOS apparaît alors comme sur sur-couche logicielle que nous devons éviter pour notre objectif, le temps réel embarqué.
### 3.2.2.3 Utilisation du langage C

Comme nous l'avons vu dans le second chapitre de ce document, les DSP peuvent être programmés soit en assembleur, soit en langage C. Si les temps d'exécution liés aux primitives des séquences de communication sont faibles en comparaison de ceux liés aux séquences de calculs définis dans l'algorithme, l'implantation sera proche du modèle d'exécution utilisé par SynDEx (parallélisme entre la séquence de communication et la séquence de calcul). En revanche, si cela n'est pas le cas, le temps d'exécution de la séquence de communication réalisée sur le CPU n'est plus négligeable : l'implantation réelle diffère du modèle d'exécution de SynDEx. Si un algorithme est décrit par un graphe flot de données faisant apparaître un grand nombre de noeuds (faible granularité du graphe), on risque de se situer dans un tel cas. La phase d'adéquation va alors aboutir à une répartition sous-optimale, les temps des communications étant négligés par rapport à la réalité. Si l'utilisation de l'assemblée permettait d'accélérer les communications, cela pourrait alors permettre de décrire les algorithmes de manière plus fine.

Dans le cas d'une architecture VLIW comme celle des C6x, le développement d'un programme en assembleur optimisé nécessite une connaissance très pointue de l'architecture interne du processeur, et de longs temps de développement pour tirer parti des huit unités fonctionnelles du CPU. D'autre part, l'utilisation de l'assemblée se justifie surtout pour des calculs spécifiques, répétitifs (DCT par exemple), comme l'ont montrées les études [BDT01]. Dans le cas des mécanismes de la séquence de communication, les opérations doivent généralement être réalisées de manière séquentielle. La puissance des compilateurs pour les récents DSP est telle qu'un programme en langage C sera pratiquement aussi performant qu'un programme assembleur pour ce type de programme. Dans ces conditions, l'utilisation de l'assemblée n'apparaît pas nécessaire en termes de performances.

En revanche, en ce qui concerne les possibilités d'évolution, le fait d'utiliser le langage C présente de nombreux avantages. Il permet de réutiliser directement le noyau pour les futurs DSP, comme les Texas Instruments C67x ou C64x. La tendance actuelle chez les fournisseurs de DSP étant des composants totalement programmables en C, le noyau créé pourra être partiellement réutisable pour de futurs DSP et processeurs. Le débogage est simplifié, sans perte notable de temps sur une application complète.

### 3.2.2.4 Division du noyau en bibliothèques

Les interfaces entre les C6x n'était pas standardisées, le noyau créé sera obligatoirement dépendant de l'architecture cible. Le travail a donc été de développer les bibliothèques correspondant d'une part aux processeurs Texas C6x (en particulier le C6201 présent sur les deux cartes), ainsi qu'aux Médias de communication SDB et CP de Sundance, et enfin aux BI-FIFO de Pentek. L'utilisation de deux plate-formes différentes a permis d'organiser le noyau afin de minimiser les changements pour son adaptation à d'autres plate-formes multi-C6x.

Le noyau d'exécutif C6x a été divisé en plusieurs bibliothèques (fig.3.15), facilitant son adaptation à une autre architecture. La bibliothèque non-générique spécifie les macros M4 pour l'application, telles que les fonctions d'appel et les entrées/sorties du système. La bibliothèque indépendante de l'architecture contient les définitions qui font l'interface entre les macros génériques et les macros des noyaux spécifiques à l'architecture et à l'application. Les autres bibliothèques sont dépendantes de l'architecture : type de processeur, de média
de communication, langage du processeur utilisé. Cette organisation permet de n'avoir que
quelques macros à redéfinir pour de nouvelles plates-formes.

3.2.3 Communications inter-C6x développées

La séquence de communication implantée sur le CPU se résume à une
machine d'état (Fig. 3.17) appelée par la séquence de calcul.

Pour développer le noyau sur cette plate-forme, les bibliothèques existantes pour les autres cibles de SynDEx sont à la base de la création de quatre bibliothèques M4 : une première dédiée aux macros spécifiques aux C6x, ensuite une pour chaque média de communications (CP.m4x et SDB.m4x) et enfin une autre pour la plate-forme (SMT335.m4x). La dernière est indispensable pour l'initialisation des paramètres de la carte Sundance. Les bibliothèques spécifiques aux média sont très proches les unes des autres et constituent de très bons exemples pour de futurs développements.

Le macro-code SynDEx de chaque processeur crée plusieurs fonctions entrelacées par-
rallélisant entre la séquence de calcul ("main") et les séquences de communications (en-
semble de fonctions de transfert appelé "thread"), reprenant le graphe figure 3.13. L'ordon-
nancement de SynDEx est statique et synchronisé par des sémaphores (Partie 2.2.2.2) de
contrôle. L'optimisation du parallélisme et du temps se fait grâce à l'usage du DMA multi-
canal du C6x (Fig. 3.16), chaque canal étant relié à un média de communication. Le C6x
peut donc avoir sur le graphe d'architecture quatre média de communication
donc quatre connexions.

Les fonctions de transfert de chaque média (envoi ou réception sur la FIFO) sont
structurées de la façon suivante :

- calcul du nombre de paquets à transmettre (partitionnement de la donnée en paquets en fonction de la taille de la FIFO),

- sélection de la FIFO,

- configuration de la FIFO,

- autorisation des interruptions,

- démarrage du DMA.

Elles correspondent aux calculs de la séquence de communication de la figure 3.16. Une fonction de communication ne dispose du séquenceur d'instructions (CPU) que pour lancer un transfert qui s'exécute, ensuite, en parallèle des opérations de calcul. Elle ne reprend qu'avec une interruption en fin de transfert. Il faut donc sauvegarder l'instruction suivante à exécuter après le transfert en cours. Ne pouvant réaliser cette sauvegarde en langage C standard, une solution a été de construire les fonctions de communications sous la forme d'une machine d'états (Fig. 3.17). Cette approche permet une cohérence maximale entre les graphes d'exécution sous SynDEx et son implantation.

Le premier sémaphore "senddata" met en œuvre une attente passive qui permet à
la séquence de calcul de continuer son exécution. Il s'agit en pratique d'attendre une
fonction "send" ou "receive" dans la séquence de calcul. Ensuite, la fonction de communi-
cation initialise le DMA pour que ce dernier effectue le transfert des données. Cette tâche
effectuée, le sémaphore "datasent" redonne la main à la séquence de calcul, pendant que le
DMA envoie ou reçoit des données. Le DMA ayant fini le transfert, il envoie le sémaphore
"fin_transfert" qui est implanté à l'aide d'une interruption.
Dans l'exécutif généré par SynDEx, le graphe d'algorithmes constitue la description d'un cycle. A chaque nouvelle entrée, l'algorithme va de nouveau être exécuté, et constitue un cycle d'exécution. Lors de la génération de code, le nombre de cycles à exécuter peut être fixé à "NB_itérations". Dans le cas contraire, l'exécutif réalisera une boucle infinie. On teste une variable globale que l'on incrémente pour connaître le nombre de cycles qui ont été exécutés ("NB_itérations" Fig. 3.17) et pour déterminer la fin de la séquence de communication.

<figure><img src="image_62.png" /><figcaption>FIG. 3.17 – Machine d'état réalisée pour l'implantation de la séquence de communication.</figcaption></figure>

Une telle implantation permet d'utiliser le CPU entre les opérations de la séquence de communication pour effectuer les opérations de la séquence de calcul, mais également d'interrompre la séquence de communication par le DMA lors de la fin des envois (Fig. 3.16). Le CPU est alors partagé entre les deux séquences, mais en offrant un parallélisme maximal grâce à l'utilisation du DMA.

La plate-forme Pentek confirme les différences entre les architectures, c'est pourquoi nous avons développé deux autres bibliothèques dépendantes du nouveau média de communication : BIFO.m4x (sans DMA) et BIFODMA.m4x (avec DMA). La version sans DMA est une version utile facilitant le débogage. De manière similaire à SMT335.m4x, nous avons réalisé Pentek.m4x pour la plate-forme. L'adaptation à cette plate-forme s'est avérée très rapide, validant nos choix suffisamment génériques.
### 3.2.4 Options de chronométrage

Le macro-code généré par SynDEx peut comporter ou non des macro de chronométrage. De cette manière, il est possible de générer automatiquement un code mono ou multi-processeurs permettant de chronométrer chaque sommet du graphe d'algorithmme et ensuite de reporter les temps sous SynDEx, pour une adéquation optimale de l'algorithmme.

Avec les C6x, il est possible de réaliser les chronométrages sans l'intégration de ces macro-code. En effet, Code Composer Studio permet d'implanter le programme avec une option de débogage et d'ajouter des points de chronométrage. Code Composer va alors compter le nombre de cycles entre les points de chronométrage, il suffit de multiplier chaque nombre de cycles par le temps de cycle (4 nanosecondes pour le C6201) pour connaître le temps d'exécution des fonctions. Cette technique comporte le défaut important d'obliger la compilation en mode de débogage, ce qui induit un exécutable sur le DSP bien moins performant que ce qui peut être obtenu en mode optimisé.

Une seconde technique peut être mise en œuvre en utilisant directement les chronomètres (timers) des C6x. Les macros de chronométrage ont été créées à l'aide des fonctions de contrôle des chronomètres réalisées par Mitsubishi ITE. Les fonctions permettent de comptabiliser le nombre de cycles entre plusieurs points du programme, à la condition que le nombre de temps de cycle soit inférieur à la taille du chronomètre, c'est-à-dire 32 bits, soit 4 secondes. Il est donc possible de compiler le programme sous Code Composer de manière optimale, d'implanter le programme sur le DSP et de visualiser les temps des fonctions associées au graphe d'algorithmme de SynDEx.

### 3.2.5 Conclusion

Le noyau SynDEx pour Texas Instruments C6x a été développé, ce qui permet dorénavant d'utiliser la génération automatique de code pour ces DSP de dernière génération. L'utilisation du langage C et la construction d'une machine d'état, permettant le partage de la séquence de communication entre le CPU et les canaux DMA, apportent une solution originale qui présente de nombreux avantages. Tout d'abord, elle évite l'usage d'un RTOS spécifique, optimisant l'implantation finale. D'autre part, elle est facilement adaptable à tout DSP et processeur utilisant ou non un DMA, de part l'utilisation du langage C. Enfin et surtout, cette solution permet un parallélisme d'exécution réel sur le DSP au plus proche du modèle décrit dans la thèse [Gra00], à la base du macro-code générique généré par SynDEx.

Le noyau permet la génération de code automatique pour toute application développée sous la version 5 de SynDEx. Les fonctionnalités de la version 6 sont actuellement ajoutées de manière progressive.

## 3.3 Applications de validation du noyau: codeur LAR et réception FM

La génération automatique de code avec SynDEx version 5, pour les C6x a été validée sur plusieurs applications d'une part de traitement d'image, sur la plate-forme Sundance, et d'autre part de traitement numérique du signal, sur Pentek.
### 3.3.1 Codeur LAR

LAR signifie "Locally Adaptive Resolution". Cette nouvelle technique de compression a été développée dans notre laboratoire [DBR00] et est utilisée pour valider la méthodologie AVS/SynDEx [Fre01]. L'algorithme est particulièrement adapté pour la transmission des images fixes sur Internet et pour les systèmes embarqués du fait de sa faible complexité. Le codeur LAR se décompose en deux couches complémentaires: un codeur spatial pour les forts taux de compression, et un second codeur pour atteindre les moyennes/hautes résolutions en compressant l'image d'erreur issue de premier codeur. Seule l'implantation du codeur spatial est présentée ici.

L'idée mise en œuvre dans la méthode LAR est d'adapter la résolution locale en fonction de l'activité: lorsque la luminance est uniforme, la résolution peut être faible (taille importante du pixel). Lorsque l'activité est forte, la résolution doit être plus fine. L'image de départ est sous-échantillonnée en blocs 16×16. Chacun de ces blocs est décomposé en blocs de taille inférieure (8×8, 4×4 ou 2×2) en fonction de l'activité locale, estimée par la mesure des gradients morphologiques dans ces blocs (suite de 4 érosions et de 4 dilatations). L'image peut être reconstruite en associant à chaque bloc la moyenne de la luminance du bloc correspondant dans l'image de départ. Cette reconstruction s'appuie sur un MICD adaptatif par bloc. La taille des blocs constitue une information sur le contenu de l'image qui s'utilise lors de la quantification. Les larges blocs sont finement quantifiés, car l'oeil s'avère très sensible aux erreurs commises sur les zones uniformes (basses fréquences). En revanche, les blocs plus petits peuvent se quantifier plus grossièrement, sans que la qualité de l'image reconstruite ne soit trop dégradée. La taille et la luminance sont également traitées par un codage arithmétique adaptatif. Le coût moyen par bloc est de quatre bits.

Le graphe flot de donnée du graphe d'algorithme de cette application a été développé sous AVS pour la vérification fonctionnelle.

La description de l'algorithme sous SynDEx a été obtenue à l'aide du traducteur automatique et permet d'extraire le parallélisme potentiel de l'application: les 4 dilatations peuvent être exécutées en même temps que les 4 érosions (Fig. 3.18).

<figure><img src="image_63.png" /><figcaption>FIG. 3.18 – *Description de l'application LAR*</figcaption></figure>

L'acquisition et le stockage des images sont effectués à l'aide de fonctions C de manipulation de fichiers (fopen et fclose) faisant communiquer le PC hôte avec les DSP. Ces
<table><caption>TAB. 3.1 – Chronométrages effectués pour l'application LAR sur C6201</caption><thead><tr><td>Fonction</td><td>DSP C40</td><td>DSP C6201</td></tr></thead><tbody><tr><td>Er 3x3</td><td>371 400 x 4</td><td>18 551 x 4</td></tr><tr><td>Dil 3x3</td><td>370 681 x 4</td><td>18 410 x 4</td></tr><tr><td>GrStep4</td><td>6 777</td><td>585</td></tr><tr><td>GrStep8</td><td>5 967</td><td>581</td></tr><tr><td>BlAver</td><td>7 558</td><td>8 344</td></tr><tr><td>DPCM</td><td>33 886</td><td>10619</td></tr><tr><td>SizCod</td><td>71 586</td><td>26 369</td></tr><tr><td>GrayCod</td><td>64 275</td><td>51 273</td></tr><tr><td>FilGray</td><td>2 816</td><td>232</td></tr><tr><td>FilSiz</td><td>2 859</td><td>243</td></tr></tbody></table>

fonction font appel aux bibliothèques fournies avec la plate-forme et engendrent des temps d'exécution importants.

Cette application a été la base du débogage et de la vérification fonctionnelle du noyau, en collaboration avec Christophe Macabiau (INRIA Rocquencourt, développeur SynDEX V6). Après la création du graphe d'algorithme, la bibliothèque M4 non générique a dû être adaptée afin de préciser le nombre d'itérations de l'algorithme et le nom des fonctions C utilisées dans le graphe.

Le code de l'implantation monoprocesseur est généré avec le noyau pour C6x, en incluant les options de chronométrage des fonctions. L'algorithme est positionné dans les différentes zones mémoire disponibles et donne les résultats suivants :

- données et programme dans SDRAM(16 KOctets): 886 ms,

- données et programme dans SBSRAM (512 KOctets): 527 ms (facteur d'accélération /SDRAM: 1.7),

- données dans SBSRAM et programme dans la mémoire interne (64 KOctets): 242 ms (facteur d'accélération /SDRAM: 3.7).

La figure 3.1 montre les résultats numériques obtenus sur un unique C40 (40 MHz) et avec un C6201 (200 MHz). Le temps complet de codage d'une image est de 3163ms sur le C40, et de 242ms sur le C6201 (Fig. 3.3.1), soit une accélération d'un facteur 12. L'architecture VLIW du C6x apporte un gain considérable, particulièrement pour les traitements de bas niveaux (érosions et dilatations).

Les temps sont reportés sous SynDEX pour la génération du code distribué optimisé sur les deux C6201 de notre plate-forme (Fig. 3.19).

Le temps pour une implantation des données en SBSRAM et du programme en mémoire interne est de 157 ms, soit une accélération de 1.68 par rapport au monoprocesseur.

### 3.3.2 Application de récepteur FM

L'équipe de radio logicielle de MITSUBISHI ITE-TCL Rennes a développé cette application de démonstration basée sur les concepts de cette discipline.
<figure><img src="image_64.png" /><figcaption>FIG. 3.19 – Architecture multi-DSP sous SynDEx</figcaption></figure>

<figure><img src="image_65.png" /><figcaption>FIG. 3.20 – Diagramme de temps LAR Schedule sur 1 et 2 DSP</figcaption></figure>
Un démodulateur FM numérique a été testé sur la plate-forme Pentek multi-DSP et exécuté en temps réel sur une chaîne numérique constituée de divers composants autour de la carte Pentek (Fig.3.10). Le signal FM a effectivement été démodulé.

Un premier DSP réalise la démodulation à partir de la carte d'acquisition, mais ne peut accéder à la carte de restitution. Une communication inter-processeurs de type bi-FIFO est nécessaire.

Les échantillons démodulés sont fournis à un second DSP, ce qui signifie que deux exécutifs doivent être chargés sur la carte cible, l'un pour l'acquisition, la démodulation et l'envoi des données au second DSP, l'autre pour la réception des données démodulées et la restitution du signal.

Le media inter-DSP peut être configuré avec ou sans l'utilisation du DMA. La version sans DMA est d'abord utilisée pour vérifier le bon fonctionnement de l'application, avant d'utiliser le DMA pour plus de parallélisme.

<figure><img src="image_66.png" /><figcaption>FIG. 3.21 – Graphe d’algorithme du démodulateur FM</figcaption></figure>

<figure><img src="image_67.png" /><figcaption>FIG. 3.22 – Diagramme temporel du démodulateur FM</figcaption></figure>

Le temps d'implantation d'une application est négligeable par rapport à sa description en graphe flot de données et sa vérification fonctionnelle. Le placement, le partitionnement et la génération d'exécutif sont effectués automatiquement.

### 3.3.3 Conclusion

Un générateur d'exécutif distribué et automatique pour des architectures multi-C6x pour SynDEx V5 a été testé sur des C6201. Il est compatible avec les autres DSP de la famille C6x. Son écriture en langage C permet sa réutilisation pour la génération de noyaux à destination d'autres processeurs ou DSP programmables en C. Les exécutifs générés sont "taillés sur mesure", évitant d'incorporer des OS et préservant l'intégrité des
ressources matérielles. Ce noyau sera utilisé lors de nos futures implantations multi-C6x, et également amélioré par ajout progressif des nouvelles fonctionnalités de SynDEx V6. Le développement du noyau a été riche en enseignements dans l'utilisation des DSP C6x, plus particulièrement pour l'utilisation des différentes mémoires, et l'écriture des fonctions C pour ces DSP.

## 3.4 Prototypage d'un codeur vidéo Mpeg-2

L'objectif est double. Premièrement, il s'agit d'introduire une méthode de conception permettant à la fois une réutilisation et des modifications simples des applications. Deuxièmement, ce travail vise le développement du processus complet pour la génération automatique de code optimal, embarqué mono et multi-DSP, dans le cadre d'applications complexes.

La première implantation que nous avons décidé de réaliser est un codeur Mpeg-2. Un codeur est a priori plus adapté à une parallélisation des tâches qu'un décodeur, puisque ce dernier doit traiter les données d'une manière imposée par le flux codé. De plus, l'obtention d'un codeur vidéo temps réel est une performance non négligeable, alors que de nombreux logiciels traitent les décodages Mpeg-2 depuis longtemps mais ne sont disponibles que depuis peu sur DSP (Décembre 2001). En 1999, nous avons décidé de débuter les développements pour un algorithme Mpeg-2, alors que le standard Mpeg-4 était dans ses premières versions et donc susceptible d'évoluer de manière assez importante. Les développements Mpeg-2 seront faits sous forme de bibliothèques, et constituerons une base pour les futurs travaux Mpeg-4.

De plus, de nombreux calculs Mpeg-2 sont utilisés dans Mpeg-4, dans le codage de la texture. Les bibliothèques décrites devront être une base dans les futurs développements Mpeg-4.

### 3.4.1 Méthode de développement

#### 3.4.1.1 Logiciel de référence TM5

Les TM (Test Model) ont été élaborés en même temps que les autres parties de la norme Mpeg-2, afin de créer des flux binaires de test. Ils constituent la partie 4 du standard Mpeg-2. Les expérimentations documentées ont été utiles pour vérifier les diverses techniques de codage proposées. Chaque proposition devait suivre les recommandations données dans le TM pour créer un nouvel encodeur Mpeg-2. Si la proposition apportait des améliorations en termes d'efficacité de codage, de complexité d'implantation ou de robustesse, la solution était conservée et intégrait le standard. Les TM spécifient des techniques qui ne font pas l'objet de normalisation, et dont les performances ne sont pas forcément optimisées.

La version utilisée est le TM5, qui a été figée en 1993 lors des réunions MPEG de Sydney (Australie). Seules quelques modifications mineures ont ensuite été apportées dans la version finale TM6.

Le TM5 nous a permis de créer le graphe flot de données du codeur Mpeg-2 correspondant sous AVS. Pour cela, il a fallu créer des bibliothèques de modules AVS faisant appel aux fonctions présentes dans le TM5.
### 3.4.1.2 Méthodes de vérification du codeur

La méthode de vérification du codeur réalisé est relativement simple : nous avons utilisé des séquences d'images, et créé un fichier associé permettant de paramétrer le codeur, tout comme pour le TM5. La première image de la séquence est alors codée avec l'application décrite sous AVS et stockée dans un fichier. Ensuite, le codeur opère les opérations de décodage pour les prédicitions dans les images suivantes. On visualise cette image sous AVS et le codeur est validé si elle correspond à l'image originale, en dehors de quelques imperfections (comme des effets de blocs) dus aux algorithmes de codage avec perte.

Le décodeur TM5 va permettre de tester la validité du flux codé en retrouvant les images visualisées sous AVS, mais aussi en vérifiant que les entêtes crées dans le flux codé sont conformes au standard.

## 3.4.2 Codage d'une séquence vidéo Mpeg-2 naturelle sous AVS

### 3.4.2.1 Bibliothèques développées sous AVS

Nous avons créé des modules sous AVS (Fig. 3.23) pour le codage Mpeg-2 de séquences vidéo rectangulaires, au profil principal, niveau principal (main@main). Le codage fonctionne pour toutes les tailles d'image, que ce soit pour un codage Intra ou Prédictif (simple ou bi-directionnel), ou pour des séquences couleur ou monochrome.

Les entrées et les sorties des modules AVS utilisent des couleurs afin de mieux visualiser leur nature sur le graphe flot de données décrivant le codeur. Les images sont en jaune, les tableaux de macroblocs en blanc, les données d'entiers en vert, et celles de réels en noir et vert. Le bleu est utilisé pour les chaînes de caractères (nom du fichier résultat) et le rose pour les variables entières.

Chacun des modules réalise une opération de base sur l'ensemble des 6 blocs de chaque macrobloc d'une image et correspond à une fonction TM5. Tout module accepte une image et les informations correspondantes en entrée, pour fournir une nouvelle image et/ou des données sur l'image courante.

Une macro a été développée pour lire un fichier paramètres ("macro"), de façon à adapter tous les autre modules du graphe au format et au nombre d'images de la séquence, a également été développé un module écrivant l'entête du fichier codé ("Putseqhd"). Cette macro met en œuvre les possibilités d'AVS en matière d'interface utilisateur, puisque ce dernier peut entrer de manière interactive les données relatives au codage qu'il veut effectuer.

Le module "motion" permet d'analyser par "block matching" le mouvement des images de la séquence afin de définir pour chaque macrobloc le voisin le plus proche, et donc réaliser la meilleure prédiction possible. Le module "predic" est utilisé pour faire le calcul de la prédiction. Le module "DCTest" qui permet de choisir si la DCT sera réalisée sur les macroblocs de manière entrelacée ou non. "rcinit" est une fonction de TM5 qui gère le contrôle du flux de manière constante ou variable. Le module "trans" commence le codage proprement dit des macroblocs, en effectuant la prédiction de mouvement et la DCT. Ensuite, le module "quant" réalise les dernières étapes du codage (quantification, scan et VLC) et écrit les données dans le fichier résultat. Les modules "itrans" et "iquant" procèdent au décodage pour simuler la réaction du décodeur et aborder les codages prédictifs suivants.

Tous ces modules correspondent aux fonctions écrites dans la partie TM5 MPEG-2.
<figure><img src="image_68.png" /><figcaption>FIG. 3.23 - Codeur Mpeg-2 développé sous AVS</figcaption></figure>

Le résultat est une application paramétrable à l'aide d'un fichier, et pouvant réaliser un grand nombre de codages différents. Dans chaque module, il existe des conditionnements qui permettent d'adapter le calcul au type d'image (I,P ou B, images entrelacées ou non), mais également au système de contrôle de débit. Il est impossible, à partir de TM5 de donner une description plus fine du codeur, de part l'entrelacement des variables trop important entre les fonctions.

Une application comme le TM5 repose sur un entrelacement de fonctions. Le lien entre ces fonctions est fait soit par passage de paramètres, soit à l'aide de variables globales disséminées dans l'ensemble des fichiers constituant la description de l'application. Cette seconde solution n'est pas compatible avec une description flot de données comme celle que nous nous proposons de réaliser. Toutes les dépendances entre noeuds du graphe doivent être définies explicitement par un lien entre ces noeuds. Cela permet à SynDEx de repérer les dépendances de données et d'effectuer un placement des tâches pour l'implantation multi-processeurs. De plus, cela est indispensable pour que le code généré transmette les données et leurs évolutions entre les différentes unités de calcul tout au long de l'application. En revanche, si toutes ces variables utilisées par TM5 doivent faire l'objet de plusieurs liens entre les noeuds du graphe, le graphe devient extrêmement complexe et lourd à manipuler. En conséquence, un grand nombre de ces variables globales ont été conservées, malgré les difficultés d'implantation multi-processeurs que cela engendre.
### 3.4.2.2 Gestion statique des buffers

Le codage Mpeg de vidéos naturelles est basé sur l'estimation de mouvement. Le codage des images B nécessite la connaissance des images codées précédemment et successivement dans l'ordre d'acquisition (Fig. 3.24).

<figure><img src="image_69.png" /><figcaption>FIG. 3.24 – Exemple de séquence Mpeg-2 avec l'ordre temporel des images, son ordre de codage et les dépendances associées</figcaption></figure>

L'ordre de codage est donc différent de l'ordre normal temporel. Il est possible de paramétrer le nombre d'images B entre deux images P, ou entre une image I et une image P. Le graphe statique doit faire apparaître des dépendances de données fixes, ce qui implique le choix d'une description temporelle figée et la définition du graphe global correspondant. Nous avons donc choisi une unique image B, ainsi qu'une image I toutes les six images (GOP de six images).

La granularité du graphe se situe au niveau image. Un cycle du graphe correspond donc à l'acquisition d'une image et au traitement complet de cette image par les différents noeuds du graphe. La récursivité temporelle entre images est exprimée à travers une unité tampon "Memory". Ce module AVS a été développé en vue d'une compatibilité avec SynDEx. Fonctionnellement, il correspond à la fonction de retard sur un cycle.

Un codeur réalise des prédictions à partir de l'image à coder et de son voisinage reconstruit. Pratiquement, le codeur est constitué de toutes les étapes de codage suivies des étapes de décodage (Fig. 3.25). Dans un premier temps, le codeur va trouver dans son voisinage le vecteur de mouvement permettant de prédire au mieux le macrobloc courant. Ensuite, les valeurs résiduelles vont être codées puis transmises. Le décodage de ces valeurs réalisé au sein du codeur a pour but de reproduire la même réaction que celle du décodeur au bitstream codé. Pour reconstruire de nouvelles images, le décodeur réalisera la prédiction inverse à partir des images reconstruites à sa disposition. Ainsi, la partie de décodage du codeur ne devra utiliser que les images précédemment reconstruites ainsi que le flux codé issu de la partie codage du codeur (Fig. 3.25). C'est donc à partir des images reconstruites que la partie codage de notre application doit réaliser la compensation de mouvement.

La figure 3.2 montre les images traitées (texte en couleur) et le contenu des différents
<figure><img src="image_70.png" /><figcaption>FIG. 3.25 – Graphe flot de données sans module "Newloop"</figcaption></figure>

<table><caption>TAB. 3.2 – Gestion des tampons mémoires par "Newloop"</caption><thead><tr><th>Itération</th><th>Image d'entrée</th><th>Memory 1</th><th>Memory 2</th><th>Image reconstruite</th><th>Memory 3</th><th>Memory 4</th></tr></thead><tbody><tr><td>0</td><td>I0</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>1</td><td>B1</td><td>I0</td><td></td><td>I0</td><td></td><td></td></tr><tr><td>2</td><td>P2</td><td>B1</td><td>I0</td><td>B1</td><td>I0</td><td></td></tr><tr><td>3</td><td>B3</td><td>P2</td><td>B1</td><td>P2</td><td>B1</td><td>I0</td></tr><tr><td>4</td><td>P4</td><td>B3</td><td>P2</td><td>B3</td><td>P2</td><td>B1</td></tr><tr><td>5</td><td>B5</td><td>P4</td><td>B3</td><td>P4</td><td>B3</td><td>P2</td></tr><tr><td>6</td><td>P6</td><td>B5</td><td>P4</td><td>B5</td><td>P4</td><td>B3</td></tr></tbody></table>

modules "Memory" en fonction du temps. Les itérations sont les temps pour lesquels une nouvelle image arrive dans la mémoire d'entrée. Les images de la séquence arrivent dans l'ordre :

I0 B1 P2 B3 P4 B5 ...

et doivent être codées dans l'ordre :

I0 P2 B1 P4 B3 P5 ...

Lors de l'arrivée de la première image dans la mémoire d'entrée, le codage de cette image peut commencer directement. Ensuite, il faut attendre deux itérations avant de pouvoir traiter l'image P2, et répéter directement l'algorithme pour l'image B1. De même, il faut attendre encore deux itérations avant de pouvoir traiter P4 et B3, et ainsi de suite.

Nous aurions pu réaliser le décodeur en transférant directement les images d'entrées et reconstruites vers les différents modules de codage et de décodage comme montré figure 3.25. Mais cela aurait entraîné trop de mouvements d'images inutiles, ainsi que des lignes de code dans chacun des modules utilisateur afin de connaître la nature de l'image dans chaque module "memory" (le tableau 3.2 montre bien l'évolution de leur contenu en fonction du temps). Le module "newloop" est alors nécessaire afin de réorganiser les tampons ainsi que
pour remettre à jour les variables avant le codage d'une nouvelles image. Le graphe flot de données correspondant est donné figure 3.26. Il diminue les transferts d'images entre modules de 36 à 21, ce qui se traduit par une diminution des transferts entre DSP et une minimisation des ressources mémoire allouées par SynDEx.

<figure><img src="image_71.png" /><figcaption>FIG. 3.26 – Graphe flot de données avec module Newloop</figcaption></figure>

### 3.4.3 Traduction AVS/SynDEx

Un certain nombre de contraintes de description pour une traduction automatique doivent être respectées :

- L'application doit posséder un unique point d'entrée (IN) et un seul point de sortie (OUT), limitation imposée dans la description SynDEx version 4.

- Les modules utilisés dans la description ne peuvent être que des modules utilisateurs. Cette contrainte est imposée par le fait qu'il faut connaître le code associé à chaque module. Cela suppose en outre que l'application ne doit pas contenir des modules AVS prédéfinis tels que ceux destinés à la création des interfaces graphiques. En pratique, cela revient à exploiter au maximum les ressources d'AVS lors de la mise au point de l'application (ajout de modules d'interface, de sorties de données multiples pour pouvoir visualiser des images intermédiaires, ...), puis de revenir à une description minimale pour le portage.

- Lorsque les entrées ou sorties sont des tableaux, elles doivent apparaître sous la forme d'un tableau contraint, autrement dit dont la taille est spécifiée lors de la définition du module. C'est une contrainte imposée par SynDEx qui réalise des allocations statiques pour les images. Sous AVS, il est possible de ne pas indiquer explicitement la taille du tableau. Elle peut être obtenue dynamiquement lors de l'exécution de la fonction associée pour un tableau en entrée. Cette taille correspond alors à celle du lien connecté au module. L'utilisateur doit délimiter dans ses programmes sources les zones propres à AVS qui devront être supprimées.

Le graphe flot de données utilisé en entrée de Syndex version 4 doit être statique, c'est à dire que les flots de données entre les modules doivent être contraints, et que toutes les images doivent suivre le même schéma quelle que soit leur nature (I, P ou B). En particulier, nous avons contraint l'application à une taille fixe d'images monochrome non
entrelacées 128x128. Étant donné que certaines conditions ne sont jamais rencontrées dans cette configuration, il a été possible de simplifier les fonctions du TM5 associées à chaque module, par exemple, en éliminant les traitements des blocs de chrominance.

S'il a été possible de restreindre la description de l'algorithme à une taille fixe d'images, en revanche, la taille du flux codé n'est a priori pas connu. Nous avons du créer un tableau de taille majorée pour pouvoir accueillir les données codées.

### 3.4.4 Implantation mono-C4x

Tout d'abord, une implantation monoprocesseur de notre algorithme a été réalisée. La complexité de programme à implanter n'a permis de réaliser que des simulations, la mémoire programme d'un C40 étant nettement insuffisante pour contenir l'application. La gestion des données relatives et le nombre d'images transitant d'un module à l'autre sont trop conséquents pour générer un code pouvant être implanté.

Une description de l'algorithme sous Syndex est donnée figure 3.27.

<figure><img src="image_72.png" /><figcaption>FIG. 3.27 – Schéma flot de donné du codeur Mpeg-2 sous Syndex</figcaption></figure>

Le temps donné pour chaque tâche a été calculé en prenant la moyenne du codage de plusieurs images de taille 120×120 dans la séquence. En effet, la complexité des tâches dépend du type I,P ou B de l'image codée, mais également du contenu et de la rapidité des mouvements dans la séquence. Les temps ont été mesurés à l'aide d'une exécution sur station de travail SPARC 10, qui a donné par le passé des résultats comparables à ceux des exécutions sur les DSP C40. De cette manière, le temps moyen de codage d'une image est évalué à 910 ms, avec la répartition des tâches mise en évidence dans la figure 3.28.

On notera que 75% du temps de codage est destiné à l'estimation de mouvement, ce qui rend l'opération de codage bien plus critique que le décodage dans les applications temps réel.

### 3.4.5 Implantation multi-C4x

Le traitement de chaque bloc doit se réaliser séquentiellement. Chaque module développé traite tous les macroblocs d'une image. SynDEx ne pourra alors réaliser le placement de ces tâches sur plusieurs DSP. Il faut fournir une description plus fine de l'algorithme pour mettre en évidence les calculs pouvant être exécutés en parallèle dans chacun de nos modules. Étant donné le poids du module d'estimation de mouvement, nous avons opéré la description plus fine sur ce module. Au lieu d'avoir un module traitant tous les macroblocs, nous avons créé trois modules prenant en charge chacun un tiers de l'image
<figure><img src="image_73.png" /><figcaption>FIG. 3.28 – Diagramme de temps dans le cas monoprocesseur</figcaption></figure>

globale (Fig. 3.29). La mise en place de cette technique est possible grâce à la notion de tranches ("slice") présentée dans le chapitre consacré à Mpeg. Il est envisageable de partager l'image en plusieurs tranches codées simultanément.

<figure><img src="image_74.png" /><figcaption>FIG. 3.29 – Division des opérations d'estimation de mouvement en trois pour un parallélisme de données</figcaption></figure>

Ainsi, SynDEx trouve une adéquation entre l’algorithme et l’architecture qui utilise les trois DSP. Le résultat est visualisé figure 3.30. Nous pouvons donc mesurer l’importance des temps de transfert inter-DSP. La figure 3.30 montre que la mise en œuvre de trois DSP pour un tel codage accélère l’estimation de mouvement d’un facteur 2, i.e. accélère le codage complet d’un facteur 1.26. Le temps de codage d’une image 120×120 passe alors de 910 ms à 720 ms.

La connaissance de cette première implantation multi-DSP nous permet d'adapter le nombre de macroblocs traités par chacun d'eux. En effet, de part son accès direct aux données, le processeur root peut traiter plus de macroblocs que les processeurs P1 et P2,
ce qui conduit à la nouvelle répartition figure 3.31.

<figure><img src="image_75.png" /><figcaption>FIG. 3.30 – Diagramme de temps pour une architecture multi-C40</figcaption></figure>

<figure><img src="image_76.png" /><figcaption>FIG. 3.31 – Diagramme de temps optimisé pour une architecture multi-C40</figcaption></figure>

Le temps de codage d'une image est maintenant de 620 ms contre 910 ms dans le cas de l'implantation monoprocesseur, soit une accélération de 1.47.

Le travail de raffinement de la description de l'algorithme que nous avons réalisé pour l'estimation de mouvement peut être effectué sur tous les autres modules du codeur. Mais devant l'importance des temps de communication comparativement à leur charge algorithmique, le temps final d'exécution ne diminuerait pas sensiblement et l'idée a été mise de coté.

### 3.4.6 Implantation sur DSP C6x

L'application de codage Mpeg-2 a pu être testée sur un unique C6201. Les mesures effectuées avec les chronomètres du DSP ont montré que le codage était réalisé en 331 ms. L'accélération par rapport aux simulations sur les C4x n'est pas spectaculaire (accélération d'un facteur 3 pour des fréquences horloge multipliées d'un facteur 5), mais a le mérite de
reposer sur une implantation réelle. Les temps mesurés s'expliquent d'une part, par l'utilisation des mémoires externes rendue obligatoire vu l'importance des ressources nécessaires, et d'autre part du fait de l'écriture complexe des codes dans TM5, ce qui empêche l'utilisation du parallélisme interne de l'architecture. Enfin, nous n'avons pas utilisé les bibliothèques fournies par Texas Instruments qui proposent des versions optimisées des fonctions de DCT, IDCT et de codage VLC.

Les variables globales étant incompatibles avec une implantation multi-DSP, nous avons simulé le comportement du codeur sur les deux DSP de notre plate-forme. Grâce aux liens rapides de communication entre les C6x, le partitionnement de l'application est efficace et permettrait d'atteindre un temps de 182ms pour une image 120×120, soit une accélération de 1.81.

### 3.4.7 Conclusions

La création d'un graphe flot de données du codeur Mpeg-2 à partir du logiciel de référence TM5 nous a permis d'acquérir une bonne expertise. Les TM sont élaborés afin de tester les méthodes proposées lors du processus de standardisation. Le résultat est un programme en C, sans aucune optimisation de code. En particulier, de nombreuses parties du code ont été écrites par différents acteurs du processus de développement Mpeg. Ces parties ont du être reliées les unes aux autres par des fonctions souvent lourdes et peu utiles (recopies de structures dans d'autres, re-définition des noms de variables, etc.). Les inclusions de bibliothèques sont nombreuses, alourdissant encore la taille du programme compilé.

Partir d'un projet comme TM5, et trouver une description flot de données qui dérive fidèlement son comportement est complexe. Les variables globales associées à plusieurs fonctions doivent être déclarées dans chaque module AVS, et être ajoutées en entrée/sortie de chacun d'eux. Le résultat est une description très chargée, difficile à analyser. D'autre part, alors que dans un programme classique, les passages de données se réalisent souvent grâce à des pointeurs, les descriptions AVS obligent de transférer toutes les données et leur duplication dans les modules utilisateurs. Les transferts de données entre les modules apportent alors des temps de communication importants. Minimiser le nombre des entrées/sorties des modules est un paramètre primordial pour une exécution rapide.

Alors que la norme offre un degré de description très fin (au niveau des blocs ou des macroblocs) bien adapté à celle de l'algorithme sous SynDEx, nous avons été obligés de créer des modules AVS très généraux. Chacun d'entre eux traite des images complètes, quelles soient de type I, P ou B. Par exemple, alors que l'estimation de mouvement est complexe pour une image B, elle est absente pour une image I. En conséquence, le temps de calcul pour une fonction associée à un module est très variable, ce qui ne permet pas à SynDEx de réaliser une bonne adéquation. Il faut créer une description adaptée aux différents cas, leur associer un temps précis et stable.

L'autre intérêt d'une description plus fine réside dans la description des opérations au niveau des macroblocs, ou encore des blocs, afin que l'adéquation optimise automatiquement le placement sur les différents DSP, sans avoir à changer la description flot de données comme nous avons pu le faire avec la division de l'estimation de mouvement en trois modules dans le codeur Mpeg-2. En effet, notre nouveau graphe flot de données a été créé manuellement, suite à l'analyse des résultats donnés par SynDEx sur une implanta-
tion sur 3 DSP. Ce travail doit être refait en fonction du nombre et de la nature des unités de calcul de la plate-forme cible, ce qui ne serait plus le cas avec une description plus fine de l'algorithme.

La création d'un graphe flot de données à partir d'un logiciel de référence Mpeg s'avère inapproprié. L'exécutif résultant n'est pas optimal, tant au niveau des temps d'exécution qu'au niveau des tailles du programme et des données.

En conséquence, réaliser une description plus fine et spécialisée s'impose. L'utilisation des documents de spécification des algorithmes du standard est la seule alternative possible pour construire un graphe d'application amenant à une implantation optimale et automatique.

## 3.5 Prototypage d'un décodeur vidéo Mpeg-4

Les travaux réalisés sur le codeur Mpeg-4 ont mis en évidence les limitations d'une méthode qui consiste, à partir d'un programme complexe séquentiel, à essayer de le décrire sous la forme d'un graphe flot de données. La granularité trop grossière du graphe ne permet alors pas d'aboutir à une implantation optimale pour un code minimal utile. La nouvelle approche consiste à réécrire complètement les fonctions opérant cette fois non plus au niveau image, mais au niveau bloc, qui constitue le grain élémentaire de la norme.

En partant réellement des fonctions de base, la méthode de description redevient alors complètement ascendante, autorisant à la fois une réutilisation des blocs fonctionnels et des descriptions hiérarchiques parfaitement en adéquation avec les besoins fonctionnels de l'application. Ainsi, la description d'un profil et d'un niveau donné sera facilitée. L'avancée actuelle des travaux se situe au niveau d'un décodeur de texture Mpeg-4 utilisable pour une application de décodage de séquences rectangulaires et directement intégrable dans de nombreux profils et niveaux Mpeg-4. Les résultats obtenus permettent déjà de valider notre approche tant sur le plan de la description fonctionnelle que sur la génération de code embarqué distribué. La méthode incrémentale de développement permet d'envisager à terme des décodeurs plus complexes, ainsi que des codeurs, utilisant les mêmes techniques de décodage de texture.

Nous allons présenter dans les paragraphes suivants la méthode de développement utilisée, les différents modules créés ainsi que leur agencement dans une application de décodage Mpeg-4. Le graphe flot de données de l'application sera ensuite utilisé dans les phases de prototypages mono et multi-DSP.

### 3.5.1 Méthode de développement

#### 3.5.1.1 Standard Mpeg-4 partie 2: codage visuel

Ce document a été la base du développement du décodeur Mpeg-4 réalisé sous AVS. Il décrit de manière précise la syntaxe d'un flux Mpeg-4, quelles en sont les variables et leur mode d'accès, que ce soit dans l'entête d'une séquence, d'un objet vidéo, ou encore d'une couche de décodage. La syntaxe est décrite en adoptant les conventions du langage C (Fig. 3.32), notamment des boucles et des tests de variables, en précisant le nombre de bits utilisés dans le flux pour chacune des variables. Cependant, la description ne peut être directement utilisée dans un décodeur, puisqu'il ne prendrait pas en compte les flux erronés.
De plus, la manière dont un décodeur doit retrouver et traiter les différents "start-code" n'est pas standardisée. Le fait d'utiliser du conditionnement et des boucles de longueur variable pour le décodage des variables de configuration du décodeur entraîne l'impossibilité de connaître a priori la position de chaque donnée dans le flux. Les entêtes ont des longueurs variables, et les données doivent alors toutes être décodées, même celles qui ne seront pas utilisées. Ce décodage est séquentiel sans aucune possibilité de parallélisme.

Par ailleurs, le document décrit de manière littérale la signification de toutes les variables que peuvent comporter les flux vidéo.

<table><caption>FIG. 3.32 – Syntaxe de description du flux codé</caption><tr><td>while ( condition ) {<br/>data element<br/>...<br/>}</td><td>If the condition is true, then the group of data elements occurs next in the data stream. This repeats until the condition is not true.</td></tr><tr><td>do {<br/>data element<br/>...<br/>} while ( condition )</td><td>The data element always occurs at least once.<br/>The data element is repeated until the condition is not true.</td></tr><tr><td>if ( condition ) {<br/>data element<br/>...<br/>} else {<br/>data element<br/>...<br/>}</td><td>If the condition is true, then the first group of data elements occurs next in the data stream.<br/>If the condition is not true, then the second group of data elements occurs next in the data stream.</td></tr><tr><td>for ( i = m; i &lt; n; i++) {<br/>data element<br/>...<br/>}</td><td>The group of data elements occurs (n-m) times. Conditional constructs within the group of data elements may depend on the value of the loop control variable i, which is set to m for the first occurrence, incremented by one for the second occurrence, and so forth.</td></tr><tr><td>* comment... *;</td><td>Explanatory comment that may be deleted entirely without in any way altering the syntax.</td></tr></table>

Seulement ensuite viennent les schémas, tables et techniques de décodage pour les différents objets vidéo. Le standard précise quels types d'objets vidéo peuvent intervenir dans chaque profil, et combien peuvent être intégrés dans chaque niveau d'un profil.

Enfin, un grand nombre d'annexes permettent de préciser certains calculs. Une partie des annexes est normative, le reste étant uniquement informatif, laissant les développeurs libres dans leur technique d'implantation.

Le standard dissémine un très grand nombre d'informations qu'il faut savoir retrouver. Étant donné que le décodeur n'implante qu'une partie des fonctionnalités décrites, le concepteur doit sélectionner les possibilités du décodage qu'il veut incorporer, et s'assurer que les flux codés autrement soient pris en charge.
### 3.5.1.2 Logiciels de référence

Comme cela avait été le cas avec les TM5 dans le standard Mpeg-2, une partie du standard est consacrée au logiciel de référence appelé MoMuSyS. MoMuSyS a été écrit en langage C. Pour donner une idée de la complexité du logiciel, et malgré le fait que MoMuSyS n'implante qu'une petite partie des fonctionnalités Mpeg-4, la taille du programme compilé en mode optimisé est de 524 KOctets (pour mémoire, nous disposons de 64 KOctets en mémoire interne d'un C6201).

Il existe un second logiciel de référence créé par Microsoft. Ce logiciel écrit en C++ réalise le codage et le décodage de séquences vidéo au format Mpeg-4. Microsoft le met à jour au fur et à mesure du processus de développement du standard, en y ajoutant des fonctionnalités. La version que nous avons utilisé date d'octobre 2001 et permet :

- le codage basique de séquences non-entrelacées,

- le codage d'un objet de forme binaire,

- le codage d'un objet de forme en niveaux de gris,

- le décodage d'objets "开了头",

- le décodage de texture fixe avec la technique des ondelettes.

Chacun de ces codecs met en œuvre une partie des fonctionnalités spécifiées dans le standard, mais pas leur totalité. Le codec Microsoft semble le plus usité et le plus à jour par rapport au développement de la norme. De nombreuses possibilités offertes par Mpeg-4 ne sont pas disponibles dans les logiciels de référence, ce qui montre une fois de plus la complexité d'une application intégrant les services Mpeg-4 les plus évolués. La taille de l'exécutable compilé de manière optimale est 444 KOctets.

L'observation pas à pas de ces deux logiciels permet de compléter efficacement les explications sur les variables d'un flux Mpeg-4 donné dans le standard.

### 3.5.1.3 Standard Mpeg-4 partie 4 : tests de conformité

Cette partie de la norme fournit un ensemble de flux codés pour tester un décodage, ainsi que des tests à réaliser sur les flux créés par un codeur. Les différentes fonctionnalités des parties du standard peuvent être testées indépendamment les unes des autres. Les tests statiques permettent de valider les algorithmes utilisés, alors que les tests dynamiques procèdent à la vérification des échantillons décodés et des contraintes de temps données par les spécifications. Pour qu'un décodeur soit conforme au standard et pour un profil@niveau donné, il doit être testé avec tous les flux fournis pour ce profil@niveau.

## 3.5.2 Décodage d'une séquence vidéo Mpeg-4 naturelle sous AVS

### 3.5.2.1 Structure d'une séquence vidéo Mpeg-4

Le flux Mpeg-4 contient les données codées, mais également des informations de configuration du décodeur (Fig. 3.33). Ces différentes parties sont multiplexées dans le flux de bits, et peuvent être démultiplexées à l'aide des "start-code" qui indiquent leur place et leur nature dans le flux. La gestion de ces informations et leur utilisation font ensuite partie de la partie système de la norme [HE00] : nous ne nous intéressons ici qu'à leur décodage.
<figure><img src="image_77.png" /><figcaption>FIG. 3.33 – *Structure logique d'un flux vidéo Mpeg-4*</figcaption></figure>

Lorsque qu'un objet vidéo possède plusieurs flux élémentaires, le premier (VOL1) permet un décodage grossier de l'objet, rapide mais de médiocre qualité. La seconde couche (VOL2) peut être ensuite décodée afin de corriger les erreurs du premier décodage. Cette deuxième étape reste facultative et permet d'obtenir une image de meilleure qualité, uniquement lorsque cela est possible, c'est-à-dire si le débit du flux est suffisamment rapide et si le décodeur réalise les calculs assez rapidement. C'est la notion de **scalabilité**. La scalabilité peut être spatiale, c'est-à-dire que le niveau de base offre une image de petite taille, rapidement décodée ou codée, et les niveaux supérieurs ajoutent des pixels à cette image, lui fournissant une meilleure résolution, si les débits et les capacités de calculs le permettent. La scalabilité peut également être temporelle, elle consiste alors pour le niveau de base à la reconstruction d'une séquence, et pour les niveaux supérieurs à l'ajout d'images complètes s'insérant dans la séquence déjà décodée, ce qui offre alors plus de fluidité à la séquence.

L'ordre de décodage des différentes entêtes d'une couche pour un objet vidéo donné est fixé et fait déjà apparaître quelques possibilités de parallélisme dans le décodage (Fig. 3.34). Un module AVS récupère le flux codé et retrouve les "start-code" pour démultiplexer les données. Le "start-code" permet d'identifier les données qui le succèdent: dans le cas d'un code spécifique au VOL, il sera suivi d'informations codées permettant de configurer le décodeur. Si il s'agit d'un code spécifique à un VOP, il sera suivi d'informations permettant d'ajuster les paramètres du décodeur et des données codées de ce VOP (appelé flux élémentaire).

Des modules AVS ont été réalisés, permettant de récupérer et de décodeur les paramètres de décodage inclus dans le flux binaire (que ce soit après un code de démarrage d'un VOL ou d'un VOP). Les noms de ces modules AVS reprennent les noms utilisés dans la norme pour décrire les flux Mpeg-4, ce qui rend plus simple la prise en main des bibliothèques (Fig. 3.35). Si les données codées correspondent à des cas que le décodeur ne peut traiter, il génère un affichage précisant l'origine du problème. Les données décodées sont fournies
<figure><img src="image_78.png" /><figcaption>FIG. 3.34 – *Parallélisme potentiel issu de la structure logique du flux Mpeg-4*</figcaption></figure>

<figure><img src="image_79.png" /><figcaption>FIG. 3.35 – *Bibliothèques AVS de gestion des flux codés*</figcaption></figure>
en sortie des modules et seront utilisées ensuite dans les modules de décodage des flux élémentaires.

Ces modules doivent être exécutés de manière séquentielle, dans l'ordre imposé par le flux codé. La division du traitement en plusieurs modules permet de ne pas multiplier le nombre des entrées/sorties sur chacun. En effet, créer un unique module qui puisse décodeur toutes les variables de configuration poserait des problèmes de lisibilité, et donc de prise en main par une tierce personne. De plus, chaque module est l'implantation d'une fonction décrite dans la norme, mais toutes les variables décodées ne sont pas mises en sortie des modules créés: seules les variables utilisées dans notre décodeur le sont, afin de ne pas surcharger un graphe déjà complexe. Le développement de nouvelles fonctionnalités amènera le développement à utiliser de nouvelles variables de configuration, qu'il devra ajouter en sortie des modules créés. Une fois une variable sélectionnée dans le standard, il n'aura aucun mal à repérer le module opérant son décodage.

On trouve dans ces bibliothèques les fonctions correspondant aux données des VOL et aux VOP :

- "VideoObjectLayer" et "VideoObjectLayer2", qui correspondent à la fonction "VideoObjectLayer" du standard.

- "DefVopComp", identique à la fonction Mpeg-4, permet, si les VOP ont été codés de manière spécifique, de définir des familles de paramètres supplémentaires.

- "VideoObjectPlaneI", implantation de "VideoObjectPlane" du standard optimisé pour images INTRA.

- "ReadVopComp", identique à la fonction Mpeg-4, décode les paramètres pour chaque famille de paramètre décodée dans "DefVopComp".

- "MacroblocI" récupère dans le flux codé le flux élémentaire d'un macrobloc, optimisé pour les images INTRA.

- "VLCinverse", permet de décodeur les données codées du flux élémentaire en six tableaux correspondant chacun à un bloc du macrobloc courant. Ce module fait également partie de cette bibliothèque car elle manipule le flux codé.

### 3.5.2.2 Décodage de la texture d'une séquence naturelle

Dans les algorithmes Mpeg-4, les images sont divisées en macroblocs (fig. 1.4) qui se succèdent dans le flux codé en partant du bord supérieur gauche de l'image, vers le bord inférieur droit. Il faut donc traiter les macroblocs dans cet ordre imposé par leur arrivée dans le décodeur.

En revanche, la description des algorithmes dans la norme se base sur les calculs sur un bloc, en fonction de son voisinage (Fig. 3.37) [EH00]. Le voisinage d'un bloc est constitué de trois blocs déjà décodés A, B et C. C'est le niveau de granularité pour la description de l'algorithme sous AVS que nous avons adopté car il correspond au grain le plus fin pour l'expression de l'ensemble des dépendances des opérateurs et des données. Étant donné que les blocs de luminance (respectivement Cb et Cr) sont décodés à partir de leurs voisinages constitués d'autres blocs de luminance (respectivement Cb et Cr), on devine des possibilités de parallélisme puisque les trois composantes peuvent être traitées indépendamment les unes des autres.

Chaque bloc d'un macrobloc est décodé selon le schéma figure 3.38.
<figure><img src="image_80.png" /><figcaption>FIG. 3.36 – Exemple de Décodage basé objet Mpeg-4</figcaption></figure>

<figure><img src="image_81.png" /><figcaption>FIG. 3.37 – Voisinage d'un bloc dans le standard Mpeg-4</figcaption></figure>

<figure><img src="image_82.png" /><figcaption>FIG. 3.38 – décodage d'un bloc 8*8 Mpeg-4.</figcaption></figure>
Les modules permettant de réaliser chacune de ces opérations (VLC inverse, direction de prédiction DC, scan inverse, prédiction des coefficients DC et AC, quantification et DCT inverses) ont été créés et regroupés dans des bibliothèques AVS. Chacun d'eux a été réduit et optimisé pour le décodage de macroblocs intra, évitant ainsi toute surcharge de code.

L'ensemble des modules nécessitant le voisinage pour réaliser le décodage a été regroupé dans un module AVS spécifique (Fig. 3.39). La DCT inverse est un algorithme classique de DCT 8x8, indépendant du voisinage du bloc traité. Le calcul de la DCT n'est pas spécifique au standard, sauf dans le cas d'objets de forme quelconque où des précautions devront être prises, et n'a donc pas été intégré dans ce module.

<figure><img src="image_83.png" /><figcaption>FIG. 3.39 – Module de décodage d'un bloc en fonction de son voisinage</figcaption></figure>

Les calculs dépendants du voisinage de chaque bloc sont :

- **Direction de prédiction DC**: il s'agit de savoir à partir de quel bloc voisin est réalisée la prédiction (Fig. 3.37). On calcule les gradients entre les voisins B et A, et B et C à l'aide des coefficients DC respectifs, ce qui permet de savoir si la dynamique est plutôt horizontale ou verticale. On sélectionne le voisin pour lequel la dynamique est la plus faible.

- **Scan inverse**: Trois tables sont disponibles pour cette opération, en fonction de la direction de prédiction calculée précédemment. Les données sont alors stockées dans un tableau 2D de la taille de l'image finale.

- **Prédiction des coefficients DC et AC**: On réalise la prédiction inverse en fonction des données stockées pour le plus proche voisin, de manière différente pour les coefficients DC et pour les coefficients AC.

- **Quantification inverse**: Il existe deux grandes méthodes de "déquantification", basées sur un paramètre récupéré dans le flux codé et appelée "quantiser_scale". Comme a priori, le décodeur ne connaît pas la technique utilisée pour coder le flux,
il est indispensable d'implanter les deux méthodes. En revanche, l'implantation d'un codeur peut contenir une seule des deux méthodes, pour simplifier les calculs, tout en restant conforme aux spécifications du standard. Ceci est un exemple typique de simplification possible pour un codeur, qu'il n'est possible d'effectuer qu'avec une bonne connaissance du standard.

### 3.5.2.3 Description hiérarchique du décodeur sous AVS

<figure><img src="image_84.png" /><figcaption>FIG. 3.40 - Niveaux hiérarchiques supérieurs du décodeur Mpeg-4</figcaption></figure>

#### Niveaux hiérarchiques supérieurs : manipulation du flux Mpeg-4

Le premier niveau de hiérarchie fait apparaître les entrées/sorties du système (Fig. 3.40). L'entrée permet de prendre en main un flux codé. C'est en quelque sorte la partie système de notre décodeur. Chaque partie entre deux "start-code" est mise dans un tableau (de taille fixe majorée) et une variable précise la valeur de ce "start-code".

Dans le cas de notre codeur, le flux codé est soit un VOL, soit un VOP (Fig. 3.33). Le conditionnement sous SynDEx V6 est réalisé à l'intérieur d'un nouveau niveau de hiérarchie, comme nous le verrons plus tard. Pour conserver la même structure, le test de la nature du flux apparaît dans le second niveau de hiérarchie, à l'aide du module AVS "IfTrue". Ce module fait partie de la bibliothèque "LogicWidgets" téléchargeable gratuitement sur le site Internet des utilisateurs d'AVS. La variable d'entrée est testée, une sortie est activée si cette variable est vraie (valeur non nulle), une seconde sortie si elle est fausse (valeur nulle) et une troisième pour tout changement de la valeur d'entrée.

Si le flux codé correspond à un VOL, le graphe de gauche du niveau 3 est activé,
c'est-à-dire la succession des modules "VideoObjectLayer", "ReadVopComp" et "VideoObjectLayer2". Sinon, c'est le graphe de droite qui sera exécuté, assurant le décodage des variables de configuration d'un VOP ("VideoObjectPlaneI" et "DefVopComplexity"). Le niveau 3 correspond au traitement d'un macrobloc, il est répété sur tous les macroblocs d'un VOP. Dans ce dernier niveau manipulant le flux codé, les modules "MacroblockI" et "VLCinverse" sont utilisés, ainsi que le module "IfTrue" qui permet de tester la fin de la répétition. Les niveaux suivants (Fig. 3.42) ne manipulent plus le flux codé directement. Une nouvelle possibilité de parallélisme apparaît puisque les niveaux inférieurs peuvent être exécutés par une unité de calcul pendant que la gestion du flux codé continue sur autre unité de calcul.

## Niveaux hiérarchiques inférieurs : décodage des différents blocs d'un macrobloc

Nous pouvons décrire un nouveau voisinage, présenté figure 3.41 et qui permet d'étendre la notion de voisinage au traitement d'un macrobloc.

<figure><img src="image_85.png" /><figcaption>FIG. 3.41 – Voisinage d'un macrobloc</figcaption></figure>

Le décodeur est décrit de manière hiérarchique, en appliquant le module de décodage Xn (Fig. 3.39) sur l'ensemble des six blocs du macrobloc et sur tous les macroblocs de l'image. Ce module de décodage correspond au niveau le plus bas de la description hiérarchique. Les données issues de ce module doivent être traitées par le module de DCT inverse, puis être stockées en mémoire pour leur utilisation lors de l'affichage. Le niveau inférieur de la description du décodeur est schématisé figure 3.42.

L'ordre d'exécution des opérations est imposé par les relations de voisinages : les blocs X2 et X3 doivent être décodés après le bloc X1, X4 après X2 et X3. Les blocs de chrominances peuvent être traités indépendamment.

La description du voisinage d'un bloc est une division implicite d'une image couleur en trois images composantes, une de luminance qui possède la même taille que l'image couleur, et deux images de chrominance, de dimensions moitiées. Par exemple, une image format CIF couleur va être constituée d'une image CIF pour la composante de luminance et de deux images format QCIF pour les composantes de chrominance. A la fin du décodage de
<figure><img src="image_86.png" /><figcaption>FIG. 3.42 - Niveaux hiérarchiques inférieurs du décodeur Mpeg-4</figcaption></figure>

chaque bloc d'un macrobloc, les données décodées sont stockées dans un module spécifique qui permet de reconstruire les trois images composantes de luminance ("StockLumPict") et de chrominance ("StockColorPict").

A chaque macrobloc traité, il faut connaître les informations de blocs contenus dans le macrobloc traité immédiatement avant (Ax, Ex, Acb, Acr), et dans deux macroblocs traités à la ligne supérieure (Bx, Cx, Dx, Bcb, Ccb, Bcr et Ccr). Pour réaliser la prédiction, un ensemble de 16 valeurs pour chacun des blocs voisins est nécessaire (Valeur DC, la première ligne et la première colonne de coefficients AC, ainsi que le pas de quantification). Ces valeurs, souvent appelées "données relatives", doivent donc être sauvegardées des itérations précédentes par des modules de mémorisation. Pour plus de lisibilité, nous n'avons pas ajouté ces modules à la figure 3.42 mais ils apparaissent sur la figure 3.43 complémentaire.

Dans les développements existants (MoMuSyS par exemple), pour chaque bloc ou macrobloc traité, une structure est allouée pour mémoriser les données relatives. Afin de ne pas multiplier le nombre de structures pour ces données relatives (et conduire à un code complexe), une unique structure est créée et doit alors comporter un grand nombre de variables pour traiter tous les types de décodages supportés par le logiciel. Plus l'application traite de cas différents, plus cette structure sera lourde et comportera un nombre de données important alors que la majeure partie d'entre elles seront rarement utilisées par la suite. Dans notre cas, les données relatives à un bloc ne seront utilisées au maximum que trois fois lors du décodage. Dans un contexte embarqué, il est important d'optimiser la mémorisation des données relatives. De plus, la diminution des valeurs mémorisées aboutit à des transferts minimaux de données, améliorant les performances sur plate-formes multi-composants.

Dans le cas de la luminance, il faut au minimum conserver les données relatives des blocs inférieurs de la ligne de macroblocs précédente Bx, Cx et Dx (Fig. 3.44 et 3.45) ainsi que celles des blocs Ax et Ex du macrobloc précédent. Étant donné la succession des
<figure><img src="image_87.png" /><figcaption>FIG. 3.43 – Mémorisation des données relatives optimisée</figcaption></figure>

<figure><img src="image_88.png" /><figcaption>FIG. 3.44 – Succession des blocs de luminance et de leur voisinage</figcaption></figure>
<figure><img src="image_89.png" /><figcaption>FIG. 3.45 - *Mémorisation optimisée du voisinage*</figcaption></figure>

macroblocs de haut en bas et de gauche à droite lors de la reconstruction, il faut alors
insérer une ligne de retard sur les blocs inférieurs de la ligne de macro bloc précédente. Cette
ligne de retard s'implante comme une FIFO à double accès lecture/écriture par cycle dont
la taille est égale au nombre de macroblocs par ligne. Lors du passage du macrobloc courant
au suivant (Fig. 3.44), les données mémorisées pour Ax et Ex peuvent être remplacées par
les données à mémoriser concernant les blocs X2 et X4 pour le macrobloc suivant. Il faut
également mettre à jour la ligne de retard avec les données relatives du macrobloc courant
qui seront utilisées lors du décodage de la ligne de macroblocs suivante.

Le raisonnement peut être fait de la même manière pour chaque composante de chro-
minance. Il est même simplifié car un macrobloc de couleur ne comporte qu'un bloc. De
cette façon, on évite la multiplication des mémoires lors du décodage. Les modules AVS
"StockBlockLum" et "StockBlockColor" mettent en œuvre cette technique optimisée (Fig.
3.43).

3.5.2.4 Vérification de l'application

Les modules créés ont du être agencés dans une application AVS complète, décrivant
un décodeur Mpeg-4. Les fonctionnalités ont été vérifiées grâce aux flux codés spécifiques
fournis dans les tests de conformité du standard.

A chaque macrobloc décodé, il est possible de visualiser le résultat à l'aide des outils
de visualisation AVS. Les entrées et les sorties sont mises à jour au fur et à mesure du
décodage, et visualisables directement dans la fenêtre d'édition AVS.

De plus, le programme peut être exécuté pas-à-pas grâce aux liens créés avec le com-
pilateur Visual C++.

Cette partie de vérification est relativement longue, puisqu'elle va valider la confor-
mité du décodeur. Deux types de problèmes sont régulièrement rencontrés: les erreurs de
décodage dans les paramètres, et celles dans le décodage du flux élémentaire. Les erreurs
de décodage de paramètres amènent des décalages dans le flux codé. Toutes les opérations qui suivent l'erreur sont erronées. Les erreurs dans le décodage d'un flux élémentaire, du fait des méthodes prédictives utilisées, provoquent des erreurs de reconstruction dans tous les macroblocs suivant l'erreur, et par la suite dans toutes les images reconstruites jusqu'à la prochaine image I décodée. L'erreur peut être arrêtée lorsqu'un macrobloc n'utilise pas son voisinage pour le codage, ce qui arrive si le codeur adopte cette possibilité.

Les modules élémentaires de décodage de texture vidéo Mpeg-4 ont été entièrement réécrits sous AVS, puis stockés dans des bibliothèques. Chaque application (codage et décodage par exemple) peut ensuite être construite à l'aide de ces modules.

Les bibliothèques Mpeg-4 peuvent être utilisées dans toute application de codage et de décodage de textures intra, c'est-à-dire dans la majorité des profils.

### 3.5.3 Traduction AVS/SynDEx

Le décodeur Mpeg-4 sous AVS utilise de nombreuses possibilités du logiciel comme :

- les macros pour créer une hiérarchie dans l'application,

- les noeuds de conditionnement prédéfinis. Ceux-ci ont été développés par les utilisateurs d'AVS qui proposent de nombreux nouveaux modules sur leur site Internet IAC [Sit],

- la définition de plusieurs points d'entrées et de sorties du graphe. C'est une possibilité offerte sous SynDEx version 6, qui nous permet par exemple de réaliser une sortie par composante de l'image.

Nous n'avons pu utiliser le traducteur automatique AVS/SynDEx mis au point pour la version 4 de SynDEx. D'une part, parce que les changements dans la syntaxe des fichiers entre les versions 4 et 5, et la version 6 sont très importants, et d'autre part, car les limitations imposées par le traducteur actuel ne nous permettent pas d'utiliser toutes les nouvelles possibilités de description de graphes sous SynDEx.

En revanche, les entrées et sorties des modules doivent toujours être des tableaux de type contraint. Comme c'était le cas pour le codeur Mpeg-2, la taille des flux à décodeur ne peut pas a priori être connue. Elle dépend de la taille des images, du débit de codage, mais également de la nature et des mouvements des images contenus dans la séquence. Les tailles des tableaux accueillant les flux codés ont donc dû être majorées.

A cette étape, nous avons une description flot de données hiérarchique vérifiée de manière fonctionnelle. D'une part, nous devons supprimer les primitives AVS que nous ne pouvons implanter, comme celles de visualisation ou de conditionnement. D'autre part, nous devons réaliser sous SynDEx une description qui garantisse l'ordre d'exécution des opérations. AVS et SynDEx ne présentent pas des modèles similaires d'activations des noeuds du graphe. Sous AVS, chaque entrée/sortie est associée à des paramètres (Fig. 3.46). Le paramètre "notify" permet d'activer le module lorsque l'entrée correspondante évolue. Les paramètres "read" et "write" permettent de lire, pour une entrée, ou d'écrire, pour une sortie, la valeur des paramètres dans la fonction associée au module. Enfin, le paramètre "req" permet de ne pas activer un module si l'entrée n'a pas de valeur associée.

De même, sous SynDEx, nous pouvons utiliser trois sortes de liens de communication entre opérations de graphe SynDEx :

- **Précédence pure.** Ce lien entre deux opérations du graphe définit uniquement la
<figure><img src="image_90.png" /><figcaption>FIG. 3.46 – Paramètres associés aux entrées/sorties sous AVS</figcaption></figure>

précédence d'une opération par rapport à l'autre.

- **Communication pure.** Le lien définit un transfert de donnée entre deux opérations, sans notion de précédence entre ces deux opérations. Ainsi, une opération pourra utiliser une variable de sortie d'une autre opération, même si celle-ci n'a pas été modifiée dans l'itération courante.

- **Communication et précédence forte.** Ce lien définit à la fois un transfert de données, mais aussi une précédence entre les opérations. Ainsi, une opération ne pourra être activée que lorsque la variable de sortie de l'opération précédente aura été modifiée.

- **Communication et précédence faible.** Ce lien est identique au cas précédent, mais la priorité de cette communication est moins importante.

L'enrichissement des liens sous SynDEx permet d'utiliser les fonctionnalités des variables d'entrées/sorties d'AVS. Ainsi, une entrée AVS ayant la propriété d'activation "notify" sera une précédence. Si cette donnée est utilisée dans la fonction (paramètre "read" activé), ce sera également une communication. Par ailleurs, si un module AVS possède plusieurs entrées de type "notify", le module pourra s'exécuter sur les changements de chacune de ces entrées (nous avons en quelque sorte un "ou" logique entre les entrées pour l'activation), alors qu'un noeud sous SynDEx ne sera exécuté que lorsque l'ensemble de ces entrées de type "précédence" auront été mises à jour dans un temps de cycle (activation et exécution de l'ensemble du graphe d'algorithme sur une nouvelle donnée d'un noeud d'entrée, s'apparentant à un "et" logique entre les entrées). Il est important de bien comprendre les deux modèles d'activation pour que les graphes soient exécutés de la même manière avec AVS et SynDEx.

Cependant, la génération de code ne permettant pas de les différencier pour l'instant, le seul lien utilisé est la communication liée à la précédence (sans niveaux de priorité puisqu'il n'y a qu'un lien possible). De plus, le fait que l'exécution des modules AVS doive être séquentielle a conduit à ajouter dans notre description des entrées/sorties d'activation afin de contraindre l'ordre d'exécution des modules du graphe. Ces entrées/sorties ont pu être retirées dans la description SynDEx.

Une autre différence entre les descriptions AVS et SynDEx concerne les noeuds de conditionnement. Sous AVS, nous utilisons un module "IfTrue" de la bibliothèque IAC, permettant d'activer une série de modules ou une autre. Le module "fin condition" (Fig. 3.47) resynchronise les deux branches, avec une entrée pour chacune d'elles autorisant son activation ("notify").

Sous SynDEx, la condition implique un nouveau niveau hiérarchique. Une entrée est testée pour exécuter un graphe ou l'autre, en fonction de sa valeur. Il n'est pas nécessaire
<figure><img src="image_91.png" /><figcaption>FIG. 3.47 – *Différence entre les conditionnements sous AVS et SynDEX*</figcaption></figure>
de faire apparaître explicitement l'ordre d'exécution des opérations qui suivent celles décrites à l'intérieur du conditionnement, l'adéquation se chargeant de trouver le meilleur séquencement possible.

De même, la construction des répétitions sous AVS et sous SynDEx n'est pas tout à fait similaire. Alors que sous AVS, cette notion s'apparente plus à un comptage du nombre de boucles et à une condition de sortie, du type "do while" en C standard, SynDEx réalise par contre une défactorisation du graphe pour un nombre fixe de répétitions, ce qui s'apparente plus à une boucle "for" en C standard.

Finalement, la version 6 de SynDEx permet de porter des applications complexes développées sous AVS, en utilisant de nombreuses possibilités offertes par ce logiciel. Pour cela, un traducteur automatique pourra être de nouveau élaboré, en même temps qu'une liste de contraintes de compatibilité pour la création de nouveaux modules et applications. La traduction de l'application de décodage Mpeg-4 sous AVS en un graphe d'algorithme SynDEx pourra être un test complet d'une telle traduction, puisqu'elle met en œuvre un grand nombre de spécificités d'AVS et toutes les fonctionnalités de SynDEx version 6.

### 3.5.4 Description du décodeur sous SynDEx version 6

Dans le second niveau, la nature du flux codé permet d'adapter le décodage du flux. Si c'est un VOL (VOL=1), un noeud traitant le décodage des informations de configuration est utilisé, si c'est un VOP, les informations relatives au VOP sont décodées, puis le flux élémentaire est traité. Les informations de configuration doivent être mémorisées pour l'itération suivante de décodage d'un VOP, d'où l'utilisation d'un noeud "memory" spécifique à SynDEx. Nous n'avons fait ressortir que les variables de configuration utiles dans notre décodeur, les autres étant forcément traitées pour qu'il n'y ait pas de décalage dans le traitement du flux.

#### 3.5.4.1 Niveaux hiérarchiques inférieurs : opérations de décodage

Dans le cas d'un VOL, le décodage ne peux être séparé en plusieurs unités de calcul puisque la récupération des bits codés est séquentielle, aucun parallélisme ne peut être opéré.

En revanche, pour le décodage d'un VOP, nous pouvons extraire plusieurs opérations : décodage des informations de VOP et de macrobloc, puis décodage du macrobloc. Le décodage des informations de VOP et de macrobloc, ainsi que les opérations de VLC inverse, sont également séquentielles. Mais le reste des opérations peut être réparti sur différentes unités de calcul, comme nous le verrons plus tard. Nous ne décrivons pas ici tous les noeuds du graphe d'algorithme sous SynDEx version 6, puisque cette description correspond celle déjà présentée sous AVS.

#### 3.5.4.2 Etude de l'ajout du PC hôte dans le graphe d'architecture de SynDEx

Une application Mpeg-4 ne peut être totalement statique. En effet, une application complète est constituée d'une partie système et de décodeurs audio et vidéo (Fig 1.18). Dans un exécutif statique, les contraintes doivent être connues au moment de la composition. Or, la partie système doit gérer de manière dynamique l'interface avec le réseau ou l'utilisateur, traiter des quantités d'information variables comme les flux. Dès lors,
<figure><img src="image_92.png" /><figcaption>FIG. 3.48 – Niveaux 1 et 2 de hiérarchie du décodeur.</figcaption></figure>
l'intégration en statique de la partie système peut être envisagée dans un contexte embarqué, mais pour une version limitée en fonctionnalités et sous-optimale du fait des majorations nécessaires. Une solution plus appropriée serait d'avoir recours à un OS à ordonnancement dynamique pour le système, tout en conservant l'exécutif statique pour les parties audio et vidéo.

Une solution matérielle serait d'utiliser la carte multi-DSP pour les opérations critiques de codage et de décodage, couplée à un processeur standard pour la gestion dynamique. On peut ainsi imaginer une reconfiguration de la plate-forme en fonction des besoins qui évoluent. Dans le cadre du partitionnement et de la gestion automatique de code, la description de la plate-forme sous SynDEx doit faire apparaître une architecture hétérogène DSP+PC hôte. Dans notre cas, il s'agit de pouvoir utiliser le port PCI (20 MOctets par seconde) existant entre la carte mère Sundance et le PC hôte. Dans le cas de la plate-forme Pentek, il s'agit d'un lien Ethernet.

Une première étape dans cette direction est étudiée dans notre laboratoire [Ven02]. Les plate-formes multi-DSP sont commercialisées comme des entités autonomes par rapport à leur PC hôte. Ceci implique, comme nous avons pu le voir pour la carte multi-C4x, de pouvoir réaliser l'acquisition/restitution des images sur la carte multi-DSP. Le but est de développer une application sur le PC pour la gestion des interfaces (fichiers, graphique) et l'échange de données via le bus PCI avec la carte multi-DSP. Ce type de réalisation ouvre de nouvelles perspectives quant à l'utilisation des cartes multi-DSP comme véritable co-processeurs du PC hôte.

A l'heure actuelle, une interface sur le PC a été développée et permet de :

- sélectionner le flux de test (fichier ".m4v" stocké sur le PC),

- effectuer la communication avec la carte multi-C6x via le bus PCI. Il s'agit d'envoyer le flux vers les C6x qui réalisent le décodage, puis de récupérer les images décodées sur le PC. La gestion des communications a été développée à l'aide de "WinDriver".

- afficher les images sur le PC en temps réel grâce aux services fournis par "Microsoft DirectX".

Les opérations sur le PC sont traitées en parallèle avec les calculs et sur la carte multi-C6x. Il faut compter entre 30 et 40 millisecondes entre la gestion des transferts, la conversion des images du format Y:U:V 4:2:0 au format d'affichage, l'envoi des données à la carte vidéo et l'affichage. Un point de synchronisation entre les deux exécutifs dans leurs cycles respectifs est obtenu par le transfert d'une image décodée. Le temps nécessaire à l'envoi d'une image QCIF est d'environ 20 ms, et de 5 ms pour une CIF (temps de synchronisation compris). Une étape future consistera à intégrer à SynDEx la génération automatique du code relatif aux communications PC/DSP.

### 3.5.5 Implantation monoprocesseur

Conformément à la méthodologie AVS/SynDEx, le décodeur a été dans un premier temps implanté sur un unique DSP C6201, grâce à la génération automatique de code de SynDEx version 5 [MRN+02]. Les intégrations des fonctionnalités de la version 6 ont été progressives, et un certain nombre d'opérations réalisées manuellement.
### 3.5.5.1 Étapes de développement du graphe

Le graphe de notre application utilise les fonctionnalités de la version 6 (répétition, hiérarchie, types de liens entre opérations et conditionnement). La génération automatique de code ne permettant pas initialement de les considérer toutes, il a fallu les intégrer au fur et à mesure au noyau SynDEx pour C6x. Ce travail a été effectué avec Mickael Raulet, en collaboration avec l'INRIA Rocquencourt qui développait le macro-code générique associé en parallèle [Rau02].

Actuellement, toute application développée avec la version 6 de SynDEx peut être portée automatiquement sur plate-forme multi-C6x. Si le graphe d'algorithme utilise la fonctionnalité de répétition, SynDEx duplique le graphe répété autant de fois qu'il y a de répétitions. Par exemple, si l'adéquation est utilisée avec 1 macrobloc, le nombre de noeuds à positionner sera de 56, pour deux macroblocs, 104 et ainsi de suite de manière linéaire. Le nombre d'opérations nécessaire à l'adéquation va quant à lui croître exponentiellement, l'adéquation ayant beaucoup plus de possibilités à explorer afin d'extraire la solution optimale. Les résultats de la figure 3.49 ont été obtenus en chronométrant l'adéquation sur un PC sous Windows XP doté d'un Pentium 3 1GHz avec des graphes de complexité croissante (RQ: ces temps ont fait apparaître un dysfonctionnement lors de la phase d'adéquation, les temps devraient donc être revus à la baisse). Au delà de mille noeuds (environ 21 macroblocs pour notre algorithme), l'adéquation se révèle longue et a de fortes chances d'échouer devant les ressources importantes qui lui sont nécessaires. Pour rappel, une image comporte 99 macroblocs pour une QCIF, et 396 pour une CIF.

<figure><img src="image_93.png" /><figcaption>FIG. 3.49 – Temps pour effectuer l'adéquation en fonction du nombre de noeuds du graphe</figcaption></figure>

D'autre part, la duplication du graphe répété a également comme conséquence de créer autant d'entrées/sorties qu'il y a de répétition, de telle sorte que l'exécutif généré devient de taille incompatible avec nos DSP.

Aussi avons nous dans un premier temps réalisé l'adéquation et la génération automatique du code pour un unique macrobloc et opéré les répétitions manuellement pour
<figure><img src="image_94.png" /><figcaption>FIG. 3.50 – Positionnement du programme et des données sur le C6201</figcaption></figure>

traiter l'ensemble du flux codé. De cette manière, l'adéquation est rapide, le code généré et les données manipulées restant de petites tailles.

### 3.5.5.2 Étapes d'optimisation du positionnement des données sur le DSP

Le partitionnement du code et des données dans les différents bancs mémoire du processeur reste une opération manuelle. Dans un projet sous "Code Composer Studio", un fichier "LNKopt.CMD" permet ce positionnement (Fig. 3.50).

La première étape consiste à implanter l'ensemble du programme et des données dans les mémoires externes du DSP, relativement lentes mais de grande capacité. Ensuite, il faut progressivement intégrer le code et les données en mémoire interne afin d'obtenir des temps plus faibles comme nous avons pu le voir sur la figure 3.6. On vérifiera que le code ne contient pas de fonctions dynamiques d'allocation, coûteuses sur les DSP. Il faudra aussi veiller à limiter les fonctions d'affichage et de manipulation de fichier, car ces dernières impliquent des communications avec le PC hôte et sont longues en regard des temps de calculs sur le DSP. Ensuite, il faudra s'assurer que les nombreuses options de compilation disponibles sous Code Composer permettent de générer un code optimisé en taille et en vitesse, ce qui inclut une compilation sans débogage. Le programme ainsi modifié sera alors minimal en taille et un maximum de données et de calculs pourront être positionnés en mémoire interne du composant. Il est vivement conseillé de vérifier à chaque modification que le résultat du décodage reste valide.

Les fonctions disponibles dans les bibliothèques Texas Instruments doivent être substituées aux fonctions développées sous AVS lors de la vérification fonctionnelle. On vérifiera que les calculs sont bien identiques en commençant par une implantation avec les fonctions AVS, avant l'utilisation des bibliothèques optimisées. Dans notre cas, seul le calcul de la DCT inverse peut être utilisé. Nous avons constaté un rapport de 20 entre les deux versions.

Nous avons pu placer l'ensemble du programme en mémoire interne, puisque la taille de l'exécutable compilé de manière optimale est de 55 KOctets pour une capacité de 64 KOctets. L'heuristique d'adéquation s'appuie sur les temps d'exécution de chaque fonction. Il est nécessaire pour le chronométrage d'utiliser les primitives de SynDEx prévues à cet
effet, et qui ont été développées pour le C6201 directement à partir de son timer, et non les possibilités de chronométrage sous Code Composer. En effet, ces dernières nécessitent une compilation en mode debug, ce qui aurait rendu impossible le placement de l'ensemble du programme en mémoire interne. Les temps d'exécution nécessaires à l'application auraient donc été erronés.

En revanche, les flux codés et les images décodées conduisent à des données trop importantes et ont du être placées en mémoire externes du C6x. Les autres données ont été positionnées en mémoire interne. Une gestion optimale des images pourrait être mise en place afin de positionner de manière dynamique une partie du flux codé et des images décodées en mémoire interne, en fonction des besoins de l'exécution.

### 3.5.5.3 Résultats finaux des chronométrages

Dans ces conditions, les résultats numériques (Tab.3.3) ont été mesurés pour chaque opération élémentaire, à l'aide des primitives de chronométrage des C6x. Les temps sont relativement stables sur tous les appels réalisés, excepté pour l'opération de VLC Inverse, qui varie énormément d'un bloc à l'autre. Dans les cas les plus rapides, l'opération prend 26 microsecondes, mais peut parfois dépasser les 280 microsecondes. La valeur de 182 microsecondes donnée dans le tableau est une moyenne sur l'ensemble des macroblocs testés sur des images de bonne qualité. Sur ce type d'images, le débit est élevé (384 KOctets/sec) et permet de conserver l'essentiel des détails contenus dans l'image, mais apporte également des temps plus élevés pour la VLC Inverse. Cette opération est critique et a déjà fait l'objet de réalisations sur architectures dédiées (ASIC ou FPGA) utilisées comme co-processeur dans des codeurs/décodeurs Mpeg-2. Il faut également préciser que des bibliothèques spécifiques au VLC Inverse Mpeg-2 pour C6x sont disponibles, mais malheureusement pas encore pour le décodage Mpeg-4. Nous avons utilisé comme base le décodage VLC Inverse de MoMuSyS, sans aucune optimisation.

Parmi les séquences des tests de conformité, seules celles mettant en œuvre la VLC inverse reversible, permettant de décoder les flux VLC dans le sens d'arrivée du flux comme dans le sens inverse, n'ont pas été encore été testées.

Les chronométrages obtenus sur les images complètes sont présentés dans le tableau 3.4. Les séquences sont issues des flux donnés dans les "conformance testing" Mpeg-4. Dans ce tableau, on peut voir que les séquences testées sont de types I ou P. Étant donné que la compensation de mouvement n'a pas été intégrée, ces flux n'ont été traités que sur la première image de la séquence qui est forcément une image codée en intra. Le temps de validation est alors le temps de la séquence donné avec chaque flux dans le standard, divisé par le nombre des images dans la séquence. Dans ces conditions, les séquences d'images I sont décodées en temps réel.

Bien que n'ayant pas de compensation de mouvement à réaliser, la reconstruction des images I reste plus longue que celle des images codées de manière prédictive (images P ou B) car ces dernières comportent peu de données à traiter et l'opération de VLC Inverse notamment s'avère alors plus rapide. Les temps obtenus sur les séquences de type P sont donc à relativiser, puisque même si le temps de validation est dépassé sur la première image de type I, le temps global de décodage de la séquence devrait être inférieur aux spécifications des tests de conformité.

D'autre part, les chronométrage ont été effectués en tenant compte des temps de trans-
<table><caption>TAB. 3.3 – Chronométrages effectués pour le décodeur Mpeg-4 sur un C6201.</caption><thead><tr><th>Fonction</th><th>Nombre d'exécutions par macrobloc</th><th>Temps d'exécution (ns)</th><th>Temps par VOP QCIF (ns)</th></tr></thead><tbody><tr><td>VideoObjectLayer</td><td></td><td>8 280</td><td></td></tr><tr><td>DefVopComp</td><td></td><td>360</td><td></td></tr><tr><td>VideoObjectLayer2</td><td></td><td>800</td><td></td></tr><tr><td>VideoObjectPlaneI</td><td></td><td>4 320</td><td>4 320</td></tr><tr><td>ReadVopComp</td><td></td><td>840</td><td>840</td></tr><tr><td>MacroBlockI</td><td>1</td><td>2 800</td><td>277 200</td></tr><tr><td>VLCInverse</td><td>1</td><td>182 859</td><td>18 103 041</td></tr><tr><td>StockBlockLum</td><td>4</td><td>4 200</td><td>1 663 200</td></tr><tr><td>StockBlockColor</td><td>2</td><td>2 810</td><td>556 380</td></tr><tr><td>DCPredictionDirection</td><td>6</td><td>770</td><td>457 380</td></tr><tr><td>InverseScan</td><td>6</td><td>3 800</td><td>2 257 200</td></tr><tr><td>InverseACDCpred</td><td>6</td><td>7 410</td><td>4 401 540</td></tr><tr><td>InverseQuant</td><td>6</td><td>11 090</td><td>6 587 460</td></tr><tr><td>InverseDCT</td><td>6</td><td>1 840</td><td>1 092 960</td></tr><tr><td>StockLumPict</td><td>1</td><td>18 630</td><td>1 844 370</td></tr><tr><td>StockColorPict</td><td>2</td><td>4 220</td><td>835 560</td></tr></tbody></table>

fert des données entre le PC et la carte multi-DSP, ce qui représente environ 20 millisecondes pour une image CIF.

### 3.5.6 Implantation multi-DSPs

L'application n'est actuellement pas complètement vérifiée sur la plateforme. La génération de code de SynDEx avec la fonctionnalité de répétition utilisée intensément apporte une taille d'exécutif importante, problématique pour le domaine embarqué. Pour expliquer ce problème, nous allons donc dans un premier temps détailler le fonctionnement de la fonctionnalité de répétition lors de l'adéquation sous SynDEx. Ensuite, nous présenterons les simulations d'implantations sur deux DSP en reportant les temps chronométrés dans le graphe de l'application sous SynDEx.

#### Notion de répétition sous SynDEx

La figure 3.51 illustre la manière dont est traitée une répétition lors de l'adéquation. Dans cet exemple, un niveau hiérarchique constitué de deux noeuds "A1" et "A2" doit être répété deux fois. Avant de réaliser l'adéquation, le graphe sera dupliqué. La description équivalent fera alors apparaître deux instances "A1R1" et "A1R2" pour "A1", de même pour "A2". Dans notre exemple, nous avons de plus ajouté une dépendance de données entre les deux instances "A1R1" et "A1R2". Si l'adéquation est réalisée sur deux processeurs, le résultat pourra être donné par un graphe temporel ou les différentes instances seront positionnées de manière optimale sur l'architecture cible. L'implantation sera réalisée sous forme de pipeline (une donnée sera traitée en "A2" pendant que la sui-
<table><caption>TAB. 3.4 – Temps de décodage des flux de test</caption><thead><tr><th>Séquence</th><th>Type</th><th>Nom</th><th>Taille</th><th>Débit (KOctets/sec)</th><th>Nombre de VOP</th><th>Temps par image (ms)</th><th>Temps de validation</th></tr></thead><tbody><tr><td>Hit000</td><td>I</td><td>Octopus</td><td>CIF</td><td>384</td><td>1</td><td>175,58</td><td>1667</td></tr><tr><td>Hit001</td><td>P</td><td>Talk</td><td>CIF</td><td>256</td><td>1</td><td>95,44</td><td>100</td></tr><tr><td>Hit002</td><td>P</td><td>Aki1</td><td>CIF</td><td>96</td><td>1</td><td>81,15</td><td>100</td></tr><tr><td>Hit003</td><td>P</td><td>Maiko</td><td>CIF</td><td>384</td><td>1</td><td>102,91</td><td>100</td></tr><tr><td>Hit004</td><td>P</td><td>Drive</td><td>CIF</td><td>256</td><td>1</td><td>110,49</td><td>100</td></tr><tr><td>Hit005</td><td>P</td><td>Talk</td><td>CIF</td><td>180</td><td>1</td><td>95,01</td><td>100</td></tr><tr><td>Hit006</td><td>P</td><td>Aki1</td><td>CIF</td><td>72</td><td>1</td><td>80,45</td><td>100</td></tr><tr><td>Hit007</td><td>P</td><td>Maiko</td><td>CIF</td><td>384</td><td>1</td><td>113,25</td><td>100</td></tr><tr><td>Hit008</td><td>P</td><td>Drive</td><td>CIF</td><td>240</td><td>1</td><td>113,45</td><td>100</td></tr><tr><td>Hit009</td><td>P</td><td>Friends</td><td>CIF</td><td>360</td><td>1</td><td>103,43</td><td>100</td></tr><tr><td>Hit010</td><td>P</td><td>Maiko</td><td>CIF</td><td>384</td><td>1</td><td>108,27</td><td>100</td></tr><tr><td>Hit011</td><td>P</td><td>Talk</td><td>CIF</td><td>256</td><td>1</td><td>102,01</td><td>100</td></tr><tr><td>Hit012</td><td>P</td><td>Aki1</td><td>CIF</td><td>64</td><td>1</td><td>88,08</td><td>100</td></tr><tr><td>Hit013</td><td>P</td><td>Octopus</td><td>CIF</td><td>80</td><td>1</td><td>127,72</td><td>100</td></tr><tr><td>Hit014</td><td>P</td><td>Drive</td><td>CIF</td><td>280</td><td>1</td><td>97,35</td><td>100</td></tr><tr><td>San000</td><td>I</td><td>Aki1</td><td>CIF</td><td>64</td><td>50</td><td>88,03</td><td>200</td></tr><tr><td>San001</td><td>I</td><td>Aki1</td><td>CIF</td><td>128</td><td>100</td><td>107,63</td><td>100</td></tr><tr><td>Jvc000</td><td>I</td><td>Friends</td><td>QCIF</td><td>384</td><td>100</td><td>43,53</td><td>100</td></tr><tr><td>Jvc001</td><td>P</td><td>Talk</td><td>CIF</td><td>384</td><td>1</td><td>107,05</td><td>66,67</td></tr><tr><td>Jvc002</td><td>P</td><td>Talk</td><td>CIF</td><td>384</td><td>1</td><td>107,05</td><td>66,67</td></tr></tbody></table>

vante sera traitée en "A1") pour des calculs en parallèles sur les différents processeurs, optimisant la cadence sur l'application totale.

Sous SynDEx, on parle de mode "flatten" puisque le graphe d'algorithmes est mis à plat avant d'être traité par l'heuristique d'adéquation. Cette mise à plat concerne également tous les niveaux hiérarchiques et les noeuds de conditionnement. Plus ces fonctionnalités seront utilisées, plus le graphe d'algorithmes traité par l'adéquation sera conséquent, plus la taille de l'exécutif et le nombre de variables créées seront importants.

Il est possible d'utiliser un mode "no flatten" qui conduit à placer lors de l'adéquation le niveau supérieur de description de l'application, sans aucune mise à plat.

## Adéquation réalisée sur un macrobloc

L'adéquation testée ici est effectuée sur un unique macrobloc, sans répétition. Le diagramme temporel généré par SynDEx (fig.3.52) permet de voir que les opérations se partagent bien sur les deux DSP.

On peut facilement observer sur le graphe temporel de SynDEx (Fig. 3.52) que le second DSP doit attendre la fin du VLC inverse exécuté sur le premier. Pour rappel, c'est ce dernier qui restitue en sortie les erreurs de prédiction quantifiées des coefficients DCT pour les six blocs d'un macrobloc. Tous les modules manipulant les flux codés, comme
<figure><img src="image_95.png" /><figcaption>FIG. 3.51 – Gestion des répétitions lors de l'adéquation.</figcaption></figure>
<figure><img src="image_96.png" /><figcaption>FIG. 3.52 – Diagramme temporel SynDEx pour le décodeur Mpeg-4.</figcaption></figure>

l'opération de VLC inverse, ont été divisés de manière à avoir une description flot de données où les noms des sommets du graphe sont soit des parties soit des noms de fonctions que l'on retrouve dans le standard. A priori, tous ces modules doivent être exécutés de manière séquentielle, sous peine de décalage dans le traitement du flux codé. Le VLC inverse récupère les flux élémentaires codés pour créer un tableau par bloc dans chaque macrobloc. Ce n'est qu'à la fin de la création de ces six tableaux que l'opération se termine, mettant en attente les traitements suivants de décodage. Il est toutefois possible de diviser cette opération en six opérations successives, mises en pipeline, (Fig. 3.53) et exécutées séquentiellement, afin de pouvoir traiter le décodage des premiers blocs de luminance du macrobloc courant, tout en continuant l'opération de VLC inverse sur les autres. Ainsi, le temps d'attente visualisé figure 3.52 se voit divisé par six.

<figure><img src="image_97.png" /><figcaption>FIG. 3.53 – Mise en pipeline de l'opération de VLC inverse</figcaption></figure>
<figure><img src="image_98.png" /><figcaption>FIG. 3.54 – *Temps d'exécution par macrobloc en fonction du nombre de macroblocs traités par l'adéquation*</figcaption></figure>

## Etude de la réalisation de l'adéquation sur plusieurs macroblocs

La complexité du graphe d'algorithmes développé réside dans la partie traitant un macrobloc de l'image. Ce sous-graphe sera répété autant de fois qu'il existe de macrobloc dans une image (soit 99 pour une QCIF et 396 pour une CIF). La complexité du graphe mis à plat (mode flatten) est alors directement proportionnelle à la taille des images.

L'implantation de l'exécutif ne peut être obtenue puisqu'il faudrait réaliser la répétition des calculs sur tous les macroblocs de l'image. Contrairement à une implantation mono-DSP, réaliser cette opération manuellement n'est pas trivial : il faut, en plus de la répétition (simple boucle), ajouter des primitives de synchronisations supplémentaires et s'assurer de la validité des valeurs sur chaque DSP en début d'une nouvelle itération. L'utilisation de la répétition sous SynDEx permettrait non seulement d'ajouter ces éléments automatiquement, mais également une optimisation des calculs en commençant le calcul d'un nouveau macrobloc sur un DSP pendant que le second termine les opérations concernant le macrobloc précédent.

Pour illustrer cet aspect, nous avons comparé le résultat de plusieurs adéquations en faisant varier le nombre de macroblocs traités, c'est-à-dire en faisant varier le nombre de répétitions. La courbe figure 3.54 montre effectivement que plus l'adéquation peut prendre en compte le traitement de macroblocs, plus le temps moyen d'exécution d'un macrobloc diminue. La courbe bleue, obtenue avec l'opération de VLC initiale, et la courbe rouge, obtenue avec l'opération de VLC décomposée en 6 modules différents, diminuent rapidement au départ, mais stagnent ensuite lorsque le nombre de macroblocs augmente.

Le nombre de noeuds à positionner par l'heuristique lors de l'adéquation étant proportionnel au nombre de macrobloc traités, les temps d'adéquations augmentent de manière exponentielle avec le nombre de macroblocs de l'image. Le temps d'adéquation n'est pas une limite puisque celle-ci doit être réalisée une fois pour une taille d'image donnée. En revanche, la taille globale des données allouées lors de la génération de code augmente de manière conséquente, tout comme la taille de l'exécutif généré sur chaque DSP (Fig.
<figure><img src="image_99.png" /><figcaption>FIG. 3.55 – Taille de l'exécutif généré en fonction du nombre de macroblocs traités par l'adéquation</figcaption></figure>

<figure><img src="image_100.png" /><figcaption>FIG. 3.56 – Taille des données allouées en fonction du nombre de macroblocs traités par l'adéquation</figcaption></figure>

3.55,3.56), ce qui devient problématique dans un contexte embarqué.

En conséquence, il apparaît clairement que l'adéquation réalisée par SynDEx doit prendre en compte la complexité engendrée par les répétitions dans un graphe d'algorithme. Actuellement, SynDEx duplique le graphe répété autant de fois qu'il y a de répétition, et tente d'opérer l'adéquation sur la totalité du graphe. Cette mise à plat est également opérée pour tous les niveaux hiérarchiques et les conditionnements. Cette solution est optimale au niveau des performances. Dans notre cas, le niveau supérieur étant très simple, le mode "no flatten" n'est pas satisfaisant puisque l'adéquation ne traite alors que quelques noeuds.

Une solution est actuellement étudiée pour pouvoir proposer à l'utilisateur des modes supplémentaires, en ne mettant par exemple à plat que les conditionnements, que les répétitions, ou que la hiérarchie. L'utilisateur pourra également choisir le niveau de granularité lors de l'adéquation, avec une mise à plat d'un ou plusieurs niveaux de hiérarchie supérieurs du graphe d'algorithme, mais pas de tous les niveaux inférieurs. Cette mise à plat "intermédiaire" permettra de choisir la granularité optimale par des tests succes-
sifs.

Une autre solution à étudier serait de réaliser la duplication de graphe répété après l'adéquation, comme le montre la figure 3.57. Cette solution serait alors moins performante, mais permettrait de simplifier la phase d'adéquation. Certaines variables de l'exécutif pourraient certainement être réutilisées dans toutes les répétitions pour diminuer les ressources utilisées. Enfin, cette solution permettrait de conserver les possibilités de parallélisme dans les niveaux hiérarchiques inférieurs, contrairement à une mise à plat "intermédiaire" précédemment présentée.

<figure><img src="image_101.png" /><figcaption>FIG. 3.57 – Répétitions prises en compte après l'adéquation.</figcaption></figure>

L'intégration de cette solution dans l'heuristique d'adéquation ne semble pas simple a priori. Cette complexité pourra dans un premier temps être minimisée par des proces-sus manuels. L'utilisateur forcera par exemple l'adéquation à utiliser la répétition avant (flatten) ou après le placement/ordonnancement (Fig. 3.57). Cette solution pourra être améliorée par la suite en divisant le nombre de répétitions total pour deux nombres dis-tincts (par exemple, l'adéquation pourra faire une mise à plat de N répétitions avant
adéquation, puis de M après adéquation, pour un total de N×M répétitions). Enfin, une
solution semi-automatique pourra être étudiée : les courbes montrent clairement qu'au delà
d'une certaine limite sur le nombre de répétitions mises à plat, le gain en performances
stagnent pour atteindre une asymptote, alors que la taille du code généré et celle des
données créées ne cessent de croître de manière linéaire, et la complexité de l'heuristique
d'adéquation de manière exponentielle. Le but de l'adéquation est d'atteindre le meilleur
compromis performances/taille de l'exécutif. Pour cela, le processus peut être envisagé de
manière événementiel sur le nombre de duplications du graphe, en stoppant l'opération
lorsqu'un gain substantiel est atteint (détermination automatique des nombres "N" et "M"
à l'aide d'un critère caractéristique de la complexité et du gain relatif). Cette solution
soulève de nombreux problèmes conceptuels et pourra faire l'objet d'études
approfondies.

Aujourd'hui encore, des travaux sont menés sur une application sur deux DSP. D'ors
et déjà, une remise en question du temps de transferts des données entre les DSP doit être
envisagée. En effet, sous SynDEx, il est nécessaire d'entrer un temps de communication
pour chaque type de données, et ce pour chaque type de média. L'adéquation estime
le temps global d'une communication en multipliant ce temps par la taille du tableau
concerné, ne prenant pas en compte le temps d'offset indispensable à la configuration de
cette communication. En conséquence, les temps que nous avons utilisés sont réalistes pour
l'émission/réception de tableaux conséquents, mais erronés dans le cas de valeurs isolées (cf
chap. 3.2.2.1). Les premiers chronométrages montrent que la granularité très fine utilisée
pour la description de l'application engendre de nombreux transferts de données de faibles
tailles, et donc des temps globaux supérieurs aux estimations faites en simulation.

3.5.7 Situation et perspectives

La description d'un décodeur Mpeg-4 a permis de prendre en main l'ensemble des do-
cuments du standard Mpeg-4. La méthode de développement utilisée est cohérente avec
le développement du standard, et permet la réutilisation des modules développés pour
de nouvelles applications. La notion de boite à outils souvent utilisée pour caractériser
les algorithmes Mpeg-4 se retrouve dans notre méthodologie. Le graphe flot de données
à grain fin de l'algorithme, suivant les descriptions fournies dans le standard, permet une
adéquation de l'algorithme, quelque soit le nombre d'unité de calculs disponibles. Les
différents niveaux de hiérarchie font qu'il est possible de réutiliser des sous-ensembles du
décodeur.

Le prototypage d'une application réalisée sous AVS s'avère rapide, avec la possibi-
lité d'utiliser un grand nombre des fonctionnalités proposées par cet outil. La traduction
du graphe flot de données AVS en un graphe SynDEx, utilisant les fonctionnalités de
répétition, hiérarchie et conditionnement, se confirme être simple. Le développement d'un
nouveau traducteur, avec la spécification des contraintes à imposer sur l'utilisation d'AVS,
permettra une traduction automatique des graphes développés sous AVS. La principale
difficulté réside dans des modes d'activation différents entre les deux outils.

La génération automatique de code optimisé par SynDEx pour C6x est validée sur une
application complexe. La version 6 de SynDEx permet de mettre en application des tech-
niques conceptuellement très complexes par rapport aux versions précédentes : hiérarchie,
répétitions d'un sommet ou d'un graphe, conditionnement. Il faut ajouter que ces tech-
niques peuvent être combinée. Dans une application complexe comme le décodage Mpeg-4,
utilisant de manière extrêmement intensive, la fonctionnalité de répétition engendre une
duplication des noeuds du graphe d'algorithme et mène à une taille d'exécutif inadaptée
au contexte embarqué. Bien que ne remettant pas en cause le processus d'adéquation et
de génération de code dans sa globalité, ce problème spécifique pourra être une base pour
l'étude de l'optimisation du code de l'exécutif généré par SynDEx.

L'utilisation des bibliothèques spécifiques aux DSP est facilitée par la description
flot de données de l'application. Une fonction non optimisée équivalente permet dans
un premier temps de réaliser la vérification fonctionnelle sous AVS. Des modules per-
mettant éventuellement de connecter la fonction aux autres précédemment développées
peuvent être créés. Ensuite, la fonction est remplacée par une version équivalente opti-
misée lors de l'implantation. La remise à jour au fur et à mesure du développement des
bibliothèques optimisées, par une tierce personne ou par le fournisseur, se réalise sim-
plement. Le développement d'une fonction optimisée dans l'opération de décodage VLC
permettra d'obtenir une parallélisation pratiquement optimale de l'algorithme. Vu qu'une
telle fonction est disponible pour Mpeg-2, il est probable qu'elle le soit également rapide-
ment pour Mpeg-4.

Plusieurs étapes doivent cependant être effectuées manuellement lors de la génération
automatique de code afin de positionner du mieux possible les données et les programmes
sur le DSP. La prise en compte des différents temps d'exécution des opérations en fonction
de leur emplacement sur les DSP, ainsi que les tailles des mémoires qu'ils possèdent, de-
vraient permettre à l'adéquation exécutée par SynDEx d'implanter automatiquement les
données et les programmes sur les différentes mémoires disponibles. L'utilisateur aurait
alors uniquement la charge de rentrer les tailles des mémoires externes et internes de son
DSP, chronométrer et reporter sous SynDEx non plus un temps d'exécution, mais plusieurs
en fonction des différents placements possibles. Le modèle de description de l'architecture
du DSP adopté par SynDEx pour réaliser l'adéquation devra être modifié pour prendre en
compte ces nouvelles caractéristiques, comme cela a pu être réalisé pour d'autres unités de
calcul [Gra00]. La génération automatique d'un code optimal embarqué pour C6x devient
alors envisageable. Ce problème global d'allocation et d'utilisation de la mémoire s'inscrit
d'ailleurs dans le travail d'une thèse débutée en septembre 2002, avec la collaboration de
l'INRIA, Mitsubishi ITE et le laboratoire IETR.

Enfin, l'ajout du PC hôte et du lien PCI sous le graphe d'architecture SynDEx va per-
mettre, entre autres, de développer la partie système des applications Mpeg-4. Cette partie
système pourra alors manipuler un ensemble de codeurs et de décodeurs dont les calculs
intensifs seront déportés sur la carte multi-DSP. On peut à plus long terme envisager que
la partie système reconfigure de manière dynamique la carte multi-DSP en fonction des
applications et des interactions avec l'utilisateur.
# Conclusion générale

Ce mémoire aborde donc les aspects méthodologiques liés au développement d'appli-
cations multimédia Mpeg sur architectures multi-composants, et plus spécialement dans le
domaine multi-DSP embarqué. L'objectif de ce travail concerne le test et le développement
de la méthodologie AVS/SynDEx en utilisant au maximum les possibilités des logiciels AVS
et SynDEx.

L'exécutif généré quasi-automatiquement par SynDEx est statique et non-résident, évitant l'utilisation d'un RTOS commercial résident. L'objectif est d'économiser un maximum les ressources (données et programmes), de diminuer les temps de calcul, mais également de pouvoir prédire les temps d'exécution indispensables pour faire du temps réel au sens strict du terme. L'utilisation d'une méthodologie de développement complète apporte des gains de temps considérables sur le temps global de développement. Grâce à ce processus de prototypage, le traiteur d'images peut concevoir son application, la vérifier fonctionnellement et éventuellement l'optimiser, pour ensuite l'implanter lui-même sans avoir recours à d'autres compétences que les siennes, la majeure partie des phases complexes (partitionnement, synchronisations intra et inter-processeurs, gestion des communications ...) étant réalisées automatiquement.

La création d'un noyau d'exécutif pour DSP Texas Instruments TMS320C6x permet
dorénavant la création automatique d'exécutifs pour ces DSP de dernière génération. La
réalisation de ce noyau sous la forme d'une machine d'état aboutit à une implantation
au plus proche du modèle de macro-exécutif générique utilisé par SynDEx, autorisant le
parallélisme d'exécution entre les séquences de calculs (sur le CPU) et les séquences de
communications (sur le CPU et les canaux DMA). Ce noyau a été développé en langage
C car la perte de temps par rapport à l'assemblée est faible, et car il pourra être adapté
rapidement à de nouveaux processeurs et DSP. Enfin, la création d'une machine d'état
constitue une base intéressante pour les futurs développements de noyaux SynDEx.

Des graphes flot de données d'applications Mpeg ont été créés sous AVS et ont été
implantés sur plates-formes multi-DSP avec le processus AVS/SynDEx. Les travaux sur
un codeur Mpeg-2 ont mis en évidence la nécessité de créer ces graphes de manière as-
cendante directement à partir du descriptif des standards Mpeg. Les connaissances ac-
cumulées ont permis la construction d'un graphe flot de données d'un décodeur Mpeg-4
parfaitement adapté à notre méthodologie. Ce graphe est basé sur l'utilisation intensive
des nouveautés de SynDEx version 6, ce qui valide les phases d'adéquation et de génération
de code pour toutes les nouvelles fonctionnalités de la version. La phase d'adéquation al-
gorithme/architecture dans le cas de répétitions intensives aboutit à une taille d'exécutif importante, posant problème dans le contexte embarqué. Le graphe d'algorithme pourra ainsi être utilisé pour de futurs travaux visant à améliorer le caractère embarqué du code automatiquement généré. Les premières implantations mono et multi-DSP permettent de valider l'approche de développement, par l'obtention de performances temps-réel sur des images CIF et QCIF (à 200 MHz), et par la limitation des ressources utilisées.

Enfin, l'ajout du PC hôte et de son lien PCI sur le graphe d'architecture SynDEx autorise maintenant la création d'une partie système complète sur un processeur standard, en profitant des nombreuses possibilités d'interfaces (utilisateurs, graphiques ou réseaux) que cela induit. La carte multi-DSP constitue alors une carte accélératrice pour les calculs de codages et de décodages vidéo ou audio.

Nos futurs travaux visent à développer les possibilités de décodage en ajoutant la compensation de mouvement et le décodage de formes quelconques, mais également en intégrant d'autres types de décodages tels que les maillages. Les modules ainsi créés seront ultérieurement utilisés dans la description de codeurs Mpeg-4. De plus, les communications inter-C6x étant possibles grâce à l'ajout d'une partie dédiée entre les DSP, fréquemment les cartes multi-DSP supportent un FPGA. Or, les études actuellement réalisées pour la synthèse automatique de VHDL à partir de SynDEx s'avèrent prometteuses et l'on pourra donc étudier les possibilités d'ajouter au graphe d'algorithme le FPGA que présente notre architecture. Enfin, les futures bibliothèques pour C6x devront être substituées dès que possible dans certaines opérations critiques comme la VLC inverse.

Les perspectives précédentes liées au prototypage dans le contexte d'un décodeur Mpeg-4 sont donc bien définies, et les résultats prévus pour un avenir proche. La méthode utilisée est bien adaptée au domaine du traitement des images, et plus généralement, à celui du traitement du signal. Des études sur des applications de radio logicielle sont d'ailleurs en cours.

La tendance actuelle tendant à l'intégration de systèmes complexes dans un unique composant, les systèmes parallèles et hétérogènes (utilisant des composants matériels) deviendront incontournables et nécessiteront la mise en œuvre d'une méthodologie adaptée comme celle présentée dans ce manuscrit.
Bibliographie

[AMT00] J. Ostermann A. Murat Tekalp. Face and 2-d mesh animation in mpeg-4. *Signal Processing: Image communication*, 2000.

[Aub98] F. Aubepart. contrôle direct du couple d'une machine asynchrone : Com- paraison entre les technologies numériques dsp et asic. *JCGE98, 4ème Conférence des Jeunes Chercheurs en Génie Électrique*, pages 245-248, Avril 1998.

[BB94] A. Benveniste and G. Berry. The synchronous approach to reactive and real-time systems. *Proc. of the IEEE*, Vol.79:pp 1270-1282, Novembre 1994.

[BDT01] *Buyer's Guide to DSP Processors*. BDTI Edition, 2001.

[BLMV98] F. Balarin, L. Lavagno, P. Murthy, and A. Sangiovanni Vincentelli. Schedu- ling for embedded real time systems. *IEEE Design and Test of Computers*, pages pp 71-82, Janvier 1998.

[Cal98] J.P. Calvez. partitioning issues in system design. *Proceedings IEEE Confe- rence on Engineering of Computer Based Systems*, pages 107-114, Mars 1998.

[CF91] M. Cosnard and A. Ferreira. The real power of loosely coupled parallel architectures. *Parallel Processing Letters*, pages pp. 103-612, 1991.

[CK96] T.L. Casavant and J.G. Kuhl. A taxonomy of scheduling in general pur- pose distributed computing systems. *IEEE Trans. Software Eng. on Image Processing*, Vol.14(No.2):pp 141-154, Novembre 1996.

[Cra99] N. Cravotta. Is mpeg-2 encoding ready for prime time. *EDN*, pages 75-82, Aout 1999.

[CS998] Multimedia information analysis and retrieval. *Computer Sciences*, (N°1464):page 196, 1998.

[DALS00] A. Dias, M. Akil, C. Lavarenne, and Y. Sorel. Vers la synthèse automatique de circuits à partir de graphes algorithmiques factorisés. *5ème Workshop AAA sur l'Adéquation Algorithme Architecture*, Janvier 2000.

[DBR00] O. Deforges, L. Bedat, and J. Ronsin. Low bit-rate compression-based on lar method for video-conference via internet. *1st IEEE International Conference on Multimedia and Expos (ICME)*, New York, USA, Août 2000.

[Dem01] D. Demigny. *Méthode et architectures pour le TSI en temps-réel*. Lavoisier, 2001.

[Den01] Franck Denoual. *Développement d'une plate-forme logicielle orientée objet pour la décompression et l'édition vidéo sur noyau temps-réel*. Thèse en informatique, Université de Rennes 1, Octobre 2001.
[DLAS98] A. Dias, C. Lavarenne, M. Akil, and Y. Sorel. Optimized implementation of real-time image processing algorithms on field programmable gate arrays. *ICSP'98 Fourth International Conference on Signal Processing*, October 1998.

[EH00] Touradj Ebrahimi and Caspar Horne. Mpeg-4 natural video coding - an overview. *Signal Processing: Image communication*, 2000.

[Ele01a] Décodeur mpeg-2 logiciel pour dsp c6000. *Electronique Internationale*, (457), Décembre 2001.

[Ele01b] Un seul circuit pour décodeur trois flux vidéo mpeg-2 simultanément. *Electronique Internationale*, (473), Novembre 2001.

[Ele02] Le prototypage d'asic avec fpga s'accélère. *Electronique Internationale*, (455), Avril 2002.

[Ern98] R. Ernst. Codesign of embedded systems: status and trends. *IEEE Design and Test of Computers*, pages pp 45-53, Avril 1998.

[FAD99] V. Fresse, M. Assouil, and O. Deforges. Rapid prototyping of image processing onto a multiprocessor architecture. *DSP World ICSPAT*, Orlando, Florida, USA, Novembre 1999.

[FBD00] V. Fresse, R. Berbain, and O. Deforges. Ptolemy as front end tool for fast prototyping into parallel and mixed architecture. *International Conference on Signal Processing Applications Technology (ICSPAT)*, Octobre 2000.

[FD02] V. Fresse and O. Deforges. ARIAL: R Apid pRototyping for mIxed and pArallel pPlatforms. Elsevier Science B.V., Décembre 2002.

[FDA00] V. Fresse, O. Deforges, and M. Assouil. Rapid prototyping for mixed architectures. *IEEE International Conference on Acoustics, Speech, and Signal Processing, Istanbul, Turkey*, Junin 2000.

[FDN02] V. Fresse, O. Deforges, and J-F. Nezan. Rapid prototyping for multi-dsp and fpga architectures: Implementation of digital image processing applications by means of avsyndex. *European Association for Signal, Speech and Image Processing (Eurasip)*, Journal on Applied Signal Processing, Implementation of DSP and Communication Systems Special Issue, 2002.

[Fre01] Virginie Fresse. *Implantation de chaînes de traitement d'images sur des architectures dédiées et mixtes*. Electronique, Institut National des Sciences Appliquées de Rennes, Février 2001.

[GLS99] T. Grandpierre, C. Lavarenne, and Y. Sorel. Optimized rapid prototyping for real time embedded heterogeneous multiprocessors. *7th International workshop on Hardware/Software Cr-Design, IEEE Computer Society, ACM SIGSOFT, IFIP, Rome, Italy*, pages pp. 74-78, Mai 1999.

[Gra00] Thierry Grandpierre. *Modélisation d'architectures parallèles hétérogènes pour la génération automatique d'exécutifs distribués temps-réel optimisés*. PhD thesis, Université Paris XI Orsay, Novembre 2000.

[Gro01] Françoise Grosvalet. Compte-rendu de l'intel developer forum. Technical report, Electronique Internationale, Septembre 2001.

[HE00] C. Herpel and A. Eleftheriadis. Mpeg-4 systems: Elementary stream management. *Signal Processing: Image communication*, 2000.
[Her02] Ivan Hermann. Etude et développement de la génération automatisée de code vhdl à partir des exécutifs générés par le logiciel syn-dex. Rapport d'avancement, IETR/INSA de Rennes / Groupe Systèmes Télécommunication Radar, Septembre 2002.

[HU99] External memory types for c6000 systems. Document technique, Hunt Engineering, Mai 1999. http://www. Hunteng.co.uk.

[Huf51] Huffman. A method for the construction of minimum redundancy. Codes. Proc. IRE 40:1098.1101, 1951.

[ISO00a] Generic coding of moving pictures and associated audio information: Systems. Document technique, ISO/IEC, 2000. http://www.iso.ch/cate/d31537.html.

[ISO00b] Generic coding of moving pictures and associated audio information: Video. Document technique, ISO/IEC, 2000. http://www.iso.ch/cate/d31539.html.

[JM98] Ahmed A. Jerraya and Jean Mermet. System-level Synthesis. NATO Science Series. Kluwer Academic Publishers, 1998.

[JTC98a] JTC1/SC29/WG11. Carriage of mpeg-4 content on mpeg-2 systems. Technical Report N2526, ISO/IEC, Octobre 1998.

[JTC98b] JTC1/SC29/WG11. Information technology - coding of audio-visual objects part 1: Systems. Technical Report N2501, ISO/IEC, Octobre 1998.

[JTC98c] JTC1/SC29/WG11. Information technology - coding of audio-visual objects part 2: Video. Technical Report N2502, ISO/IEC, Octobre 1998.

[JTC99] JTC1/SC29/WG11. Mpeg-4 applications. Technical Report N2724, ISO/IEC, Octobre 1999.

[KLZ97] Y. Kopidakis, M. Lamari, and V. Zissimopoulos. On the task assignment problem: Two new efficient heuristic algorithms. Journal of Parallel and Distributed Computing, Vol.42:pp 21-29, 1997.

[KMRL01] A. Kountouris, C. Moy, L. Rambaud, and P. Lecorre. Reconfigurable radio case study: A software based multi-standard transceiver for umts, gsm, ejge and bluetooth. IEEE Vehicular Technology Conference (VTC), Atlantic City, USA, Octobre 2001.

[Koe00] R. Koenen. Profiles and levels in mpeg-4: approach and overview. Signal Processing: Image communication, 2000.

[LB90] E.A. Lee and J.C. Bier. Architectures for statically scheduled dataflow. Journal of Parallel and Distributed Computing, pages pp 333-348, 1990.

[Leh01] Janne Lehtomäki. Transform domain lms. Adaptative Filters Seminar, 2001.

[LHF91] B. Lee, A.R. Hurson, and T.-Y. Feng. A vertically layered allocation scheme for data flow systems. Parallel and Distributed Computing, Vol.11:pp 175-187, 1991.

[LO96] M. Loukides and A. Oram. Programming with GNU software. O'Reilly, 1996.

[LSSS91] C. Lavarenne, Y. Sorel, O. Seghrouchni, and M. Sorine. Syndex un environnement de programmation pour application de traitement du signal distribué. 13ème colloque GRETSI, Septembre 1991.

[LS] C. Lavarenne and Y. Sorel. Specification, performance optimization and executive generation for real-time embedded mujtiprocessor application with
syndex. Proc. Of Real Time Embedded Processing for Space Applications, CNES International Symposium.

[LW02] P. Leray and J. Weiss. Technologies soc (system on ships). Journée recherche Supélec Campus de Rennes, Février 2002.

[MLNPM99] C. Miro, A. Lafage, Q.L. Nguyen-Phuc, and Y. Mathieu. Hardware implementation of perspective transformations on mpeg-4 video objects. Proceedings of SPIE, vol. 3695 Media Processors:pp. 402–312, 1999.

[MR01] Y. Le Méner and M. Raulet. Développement d'un noyau temps réel pour dsp c6x intégré dans le générateur de code distribué syndex pour architectures multiprocesseurs. Technical report, Mitsubishi ITE & UMR CNRS 6164 IETR INSA Rennes, Sept 2001.

[MRN+02] Y. Le Mener, M. Rauler, J-F. Nezan, A. Kountouris, and C. Moy. Syndex executive kernel development for dsps ti c6x applied to real-time and embedded multiprocessors architectures. European Signal Processing Conference (Eusipco), Toulouse, France, Septembre 2002.

[NDF01] J-F. Nezan, O. Deforges, and V. Fresse. Intégration rapide de services vidéo mpeg sur architectures parallèles. Colloque GRETSI sur le traitement du Signal et des images, Toulouse, France, Septembre 2001.

[NDR02] J-F. Nezan, O. Deforges, and M. Raulet. Rapid prototyping methodology for multi-dsp ti c6x platforms applied to an mpeg-2 coding application. Symposium on Parallel Algorithms and Architectures (SPAA), Winnipeg, Canada, Août 2002.

[NFD01] J-F. Nezan, V. Fresse, and O. Deforges. Fast prototyping of parallel architectures: an mpeg-2 coding application. International Conference On Imaging Science, Systems and Technology (CISST), Las Vegas, USA, Juin 2001.

[NFDR02] J-F. Nezan, V. Fresse, O. Deforges, and M. Raulet. Avsyndex methodology for fast prototyping of multi-c6x dsp architectures. International Conference on Parallel and Distributed Processing Techniques and Applications (PDPTA), Las Vegas, USA, Juin 2002.

[Nou01] S. Le Nours. Portage d'algorithmes mc-cdma sur plate-forme mixte de prototypage. Rapport d'avancement, IETR/INSA de Rennes / Groupe Systèmes Télécommunication Radar, Octobre 2001.

[PDG95] P. Pirsch, N. Demassieux, and W. Gehrke. Vlsi architectures for video compression, a survey. Proceedings of the IEEE, 83(2):220–245, Février 1995.

[PE02] Fernando Pereira and Touradj Ebrahimi. The Mpeg-4 book. IMSC Press Multimedia Series, Septembre 2002.

[Per00] Fernando Pereira. Mpeg-4: why, what, how and when? Signal Processing: Image communication, 2000.

[PTB+92] P.Ruetz, P. Tong, D. Bailey, D. A. Luthi, and P.H. Ang. A high-performance full motion video compression chip set. IEEE Trans. Circ. and Syst. For Video Technol., 2:111–122, 1992.

[Rau02] M. Raulet. Hardware resource and software application description methodology for several processing boards on ti c6x dsp processors. Technical report, Mitsubishi ITE & UMR CNRS 6164 IETR INSA Rennes, Juin 2002.
[Ris76] Rissanen. Generalized kraft inequality and arithmetic coding. *IBM journal research and development*, Mai 1976.

[SAK95] B.A. Shirazi, A.Hurson, and K.M. Kavi. Scheduling and load balancing in parallel and distributed system. *IEEE Computer Society Press*, 1995.

[SDB01] E. Sicard and S. Delmas-Bendhia. Une introduction aux dsp. Technical report, INSA Toulouse, Juin 2001.

[SFE00] Julien Signès, Yuval Fisher, and Alexandros Eleftheriadis. Mpeg-4's binary format for scene description. *Signal Processing: Image communication*, 2000.

[Sit] International avs center (iac), www.iavsc.org.

[Sor99] Carolina Miro Sorolla. *Architecture d'un accélérateur matériel pour la composition d'objets vidéo Mpeg-4*. Thèse en electronique et communications, Ecole Nationale Supérieure des Télécommunications, 1999.

[SRAB00] S. Srikanteswara, J-H. Reed, P. Athanas, and R. Boyle. A soft radio architecture for reconfigurable platforms. *IEEE Communications Magazine*, Février 2000.

[Sta] John A. Stankovic. Real-time and embedded systems. Technical report, Université de Massachusetts.

[SVH99] E.D. Scheirer, R. Vaananen, and J. Huopaniemi. Audiobifs: describing audio scenes with the mpeg-4 multimedia standard. *IEEE Transactions On Multimedia*, Vol 1(N°3), Septembre 1999.

[SW97] J. Staunstrup and W. Wolf. *Hardware Software Co-Design, Principles and Practice*. Kluwer Academic Publishers, 1997.

[TIa01] Tms320c6000 programmer's guide. Document Technique Ref. spru198f, Texas Instruments, Février 2001. http://www.dspvillage.ti.com.

[TIb00] Tms320c6000 code composer studio - tutorial. Document Technique Ref. spru301c, Texas Instruments, Février 2000. http://www.dspvillage.ti.com.

[Val98] Carlos Alberto Valderrama. *Prototype virtuel pour la génération des architectures mixtes logicielles/matérielles*. Thèse en micro-électronique, Institut National Polytechnique de Grenoble, Octobre 1998.

[VC99] L. Vanderdorpe and L. Cuvelier. Statistical properties of coded interlaced and progressive image sequences. *IEEE Transactions On Image Processing*, Vol 8(N°6), Juin 1999.

[Ven02] N. Ventroux. Développement d'interfaces graphiques et de liens de communication PCI pour architectures distribuées pc-plateforme multi-c6x. Technical report, UMR CNRS 6164 IETR INSA Rennes, Septembre 2002.

[Wan91] M. Wang. Accurate communication cost estimation in static task scheduling. *Hawaii Int. Conference System Sciences*, Vol.I:pp 10-16, 1991.

[YG93] T. Yang and A. Gerasoulis. List scheduling with and without communication delays. *Parallel Computing Journal*, Vol.19:pp 1321-1344, 1993.
<figure><img src="image_102.png" /></figure>
<figure><img src="image_103.png" /></figure>
RESUME

Les performances de l'informatique à la hausse et le spectaculaire essor de l'Internet sont à l'origine de nouveaux modes de communication. Après la parole et les textes, il s'agit de pouvoir transmettre des documents audio, vidéo ou encore un ensemble constitué de tous ces éléments synchronisés. L'élaboration du standard international Mpeg-4 est alors devenu une nécessité pour faciliter ces échanges en établissant une représentation compacte de tels documents.

L'utilisation d'applications multimédia dans le domaine embarqué est déjà pris en compte dans l'élaboration de Mpeg-4. Les systèmes temps-réels embarqués sont caractérisés par des ressources et une puissance de calcul limitées, ce qui rend l'implantation et le respect des contraintes de temps difficiles. Une nouvelle application doit non seulement être validée fonctionnellement, mais doit également prouver ses aptitudes temps réel. Dès lors, la première approche consiste à optimiser l'algorithme puis à s'intéresser à l'aspect matériel en choisissant une architecture capable de supporter les contraintes imposées. Une architecture constituée de plusieurs unités de calcul est souvent nécessaire.

Ces observations ont poussé le laboratoire IETR/INSA de Rennes groupe Image à définir une méthodologie de développement adaptée. Cette méthodologie appelée AVS/SynDEx permet de développer des applications à un haut niveau d'abstraction, de les vérifier fonctionnellement avant de les implanter de manière semi-automatique sur des plate-formes parallèles, constituées de composants de même types, de même familles, ou encore hétérogènes.

Les travaux ont porté à la fois sur la description fonctionnelle sous forme de graphes flots de données d'applications Mpeg, et de leur prototypage rapide sur architectures mono et multi-C6x grâce au développement d'un noyau d'exécutif adapté. L'objectif est double : d'une part élargir et valider la méthodologie AVS/SynDEx pour des chaînes de traitement conséquentes ; d'autre part offrir une méthode de développement pour Mpeg-4 suffisamment souple et permettant d'aboutir à des solutions d'implantations mono et multi-processeurs optimisées en fonction du niveau de service voulu.

Un codeur Mpeg-2, ainsi qu'un décodeur Mpeg-4 ont permis de valider le noyau d'exécutif SynDEx pour C6x, et de mettre en évidence la nécessité d'une construction ascendante des graphes. Les performances temps-réel sont atteintes pour le décodage vidéo CIF en mono-C6x. Le portage en multi-DSP est semi-automatique et apporte des accélérations conséquentes. Le décodeur Mpeg-4 et le noyau d'exécutif basé sur l'implantation d'une machine d'état en langage C, pourront être repris partiellement ou dans leur globalité pour des développements ultérieurs.