<figure><img src="image_1.png" /></figure>

HAL
open science

# Intégration de services vidéo Mpeg sur architectures parallèles

Jean-François Nezan

► To cite this version:

Jean-François Nezan. Intégration de services vidéo Mpeg sur architectures parallèles. Calcul parallèle, distribué et partagé [cs.DC]. INSA RENNES, 2002. Français. NNT: 2002ISAR0008 . tel-04292101

HAL Id: tel-04292101

https://hal.science/tel-04292101

Submitted on 17 Nov 2023

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

Public Domain
## THÈSE

présentée à l'I.N.S.A. de Rennes

pour obtenir le grade de :

DOCTEUR DE L'INSTITUT NATIONAL DES SCIENCES APPLIQUÉES
DE RENNES

Mention : Traitement du Signal

par

Jean-François Nezan

UMR CNRS 6164
IETR/INSA DE RENNES
GROUPE IMAGE

École doctorale MATISSE

Titre de la thèse :

Intégration de services vidéo Mpeg sur architectures parallèles

Soutenue le 22 novembre 2002

COMPOSITION DU JURY :

Mme Françoise PRÊTEUX (INT) Rapporteurs
M. Yves SOREL (INRIA)

MM. Dominique CURET (France Telecom R&D) Examinateurs
Pierre Jean GUERY (Mitsubishi Electric Telecom Europe-IPSIS)
Joseph RONSIN (IETR Groupe Image)
Olivier DÉFORGES (IETR Groupe Image)
<figure><img src="image_2.png" /></figure>
## THÈSE

présentée à l'I.N.S.A. de Rennes

pour obtenir le grade de :

DOCTEUR DE L'INSTITUT NATIONAL DES SCIENCES APPLIQUÉES
DE RENNES

Mention : Traitement du Signal

par

Jean-François Nezan

UMR CNRS 6164
IETR/INSA DE RENNES
GROUPE IMAGE

École doctorale MATISSE

Titre de la thèse :

# Intégration de services vidéo Mpeg sur architectures parallèles

Soutenue le 22 novembre 2002

COMPOSITION DU JURY :

Mme Françoise PRÊTEUX (INT) Rapporteurs
M. Yves SOREL (INRIA)

MM. Dominique CURET (France Telecom R&D) Examinateurs
Pierre Jean GUERY (Mitsubishi Electric Telecom Europe-IPSIS)
Joseph RONSIN (IETR Groupe Image)
Olivier DÉFORGES (IETR Groupe Image)
<figure><img src="image_3.png" /></figure>
# Table des matières

Table des figures 4

Liste des tableaux 9

Introduction générale 11

1 Introduction aux techniques de codage et aux standards Mpeg 13

1.1 Généralités 14

1.1.1 Généralités sur les images numériques 14

1.1.2 Compression d'images fixes 16

1.1.3 Normes Mpeg 19

1.2 MPEG-2: standard de codage vidéo 22

1.2.1 Introduction 22

1.2.2 Décomposition de la séquence vidéo 22

1.2.3 Codage intra-image 23

1.2.4 Codage prédiktif 25

1.2.5 Schéma global 26

1.3 MPEG-4: standard pour applications multimédias 27

1.3.1 Introduction 27

1.3.2 Organisation de la norme, Profiles@Levels 29

1.3.3 Notion de scène - BIFS (Binary Format for Scene description 33

1.3.4 Codage des objets 35

1.3.5 DMIF: Delivery Multimedia Integration Framework 39

1.3.6 Protection et gestion de la propriété intellectuelle - IPMP 40

1.3.7 Protocole de transmission: partie système 40

1.4 Besoins pour Mpeg-4 42

2 Analyse des architectures matérielles 45

2.1 Présentation des unités de calcul 45

2.1.1 Processeurs standard 45

2.1.2 Processeurs de traitement du signal: DSP 47

2.1.3 Circuits spécialisés 53

2.1.4 Comparaisons des différents circuits spécialisés 56

2.1.5 Architectures multi-composants 58

2.1.6 Complexité de mise en œuvre 60

2.2 Systèmes temps réel de traitement des images 61
<table><tbody><tr><td>2.2.1</td><td>Exécutif temps réel embarqué</td><td>61</td></tr><tr><td>2.2.2</td><td>Systèmes d'exploitation temps réel</td><td>63</td></tr><tr><td>2.2.3</td><td>Spécificités du traitement des images</td><td>68</td></tr><tr><td>2.3</td><td>Méthodologies de conception de systèmes embarqués temps réel</td><td>69</td></tr><tr><td>2.3.1</td><td>MCSE</td><td>70</td></tr><tr><td>2.3.2</td><td>Pegasus</td><td>72</td></tr><tr><td>2.3.3</td><td>AVS/SynDEx</td><td>72</td></tr><tr><td>2.4</td><td>Synthèse</td><td>83</td></tr><tr><td>3</td><td>Descriptions et intégrations d'applications Mpeg</td><td>87</td></tr><tr><td>3.1</td><td>Plate-formes utilisées</td><td>88</td></tr><tr><td>3.1.1</td><td>Plate-forme multi-C4x</td><td>88</td></tr><tr><td>3.1.2</td><td>Plate-forme multi-C6x</td><td>91</td></tr><tr><td>3.2</td><td>Noyaux d'exécutifs génériques synchronisés</td><td>97</td></tr><tr><td>3.2.1</td><td>Principes des exécutifs synchronisés</td><td>97</td></tr><tr><td>3.2.2</td><td>Méthode utilisée</td><td>103</td></tr><tr><td>3.2.3</td><td>Communications inter-C6x développées</td><td>106</td></tr><tr><td>3.2.4</td><td>Options de chronométrage</td><td>108</td></tr><tr><td>3.2.5</td><td>Conclusion</td><td>108</td></tr><tr><td>3.3</td><td>Applications de validation du noyau: codeur LAR et réception FM</td><td>108</td></tr><tr><td>3.3.1</td><td>Codeur LAR</td><td>109</td></tr><tr><td>3.3.2</td><td>Application de récepteur FM</td><td>110</td></tr><tr><td>3.3.3</td><td>Conclusion</td><td>112</td></tr><tr><td>3.4</td><td>Prototypage d'un codeur vidéo Mpeg-2</td><td>113</td></tr><tr><td>3.4.1</td><td>Méthode de développement</td><td>113</td></tr><tr><td>3.4.2</td><td>Codage d'une séquence vidéo Mpeg-2 naturelle sous AVS</td><td>114</td></tr><tr><td>3.4.3</td><td>Traduction AVS/SynDEx</td><td>118</td></tr><tr><td>3.4.4</td><td>Implantation mono-C4x</td><td>119</td></tr><tr><td>3.4.5</td><td>Implantation multi-C4x</td><td>119</td></tr><tr><td>3.4.6</td><td>Implantation sur DSP C6x</td><td>121</td></tr><tr><td>3.4.7</td><td>Conclusions</td><td>122</td></tr><tr><td>3.5</td><td>Prototypage d'un décodeur vidéo Mpeg-4</td><td>123</td></tr><tr><td>3.5.1</td><td>Méthode de développement</td><td>123</td></tr><tr><td>3.5.2</td><td>Décodage d'une séquence vidéo Mpeg-4 naturelle sous AVS</td><td>125</td></tr><tr><td>3.5.3</td><td>Traduction AVS/SynDEx</td><td>136</td></tr><tr><td>3.5.4</td><td>Description du décodeur sous SynDEx version 6</td><td>139</td></tr><tr><td>3.5.5</td><td>Implantation monoprocesseur</td><td>141</td></tr><tr><td>3.5.6</td><td>Implantation multi-DSPs</td><td>145</td></tr><tr><td>3.5.7</td><td>Situation et perspectives</td><td>152</td></tr></tbody></table>
Table des figures

<table><tr><td>1.1</td><td>Schéma global d'un décodeur Mpeg-1.</td><td>19</td></tr><tr><td>1.2</td><td>Organisation des versions dans le standard Mpeg-4</td><td>21</td></tr><tr><td>1.3</td><td>Enchaînement des images dans un GOP.</td><td>22</td></tr><tr><td>1.4</td><td>Un macrobloc au format 4:2:0.</td><td>23</td></tr><tr><td>1.5</td><td>Schéma global du codage intra-image.</td><td>24</td></tr><tr><td>1.6</td><td>Zig-Zag scan et alternate scan.</td><td>24</td></tr><tr><td>1.7</td><td>Codage prédictif simple.</td><td>25</td></tr><tr><td>1.8</td><td>Codage prédictif avec compensation de mouvement.</td><td>26</td></tr><tr><td>1.9</td><td>Schéma de codage prédictif avec compensation de mouvement.</td><td>27</td></tr><tr><td>1.10</td><td>Exemple d'infotainment.</td><td>29</td></tr><tr><td>1.11</td><td>Objets audiovisuels organisés en scène.</td><td>34</td></tr><tr><td>1.12</td><td>Manipulation d'une scène.</td><td>35</td></tr><tr><td>1.13</td><td>Schéma global de codage d'objets vidéo de forme quelconque.</td><td>37</td></tr><tr><td>1.14</td><td>Exemple de coefficients caractéristiques du visage.</td><td>38</td></tr><tr><td>1.15</td><td>Exemple de maillage 2D.</td><td>39</td></tr><tr><td>1.16</td><td>Architecture DMIF.</td><td>40</td></tr><tr><td>1.17</td><td>Les points de contrôle IPMP dans le schéma global de codage</td><td>41</td></tr><tr><td>1.18</td><td>Architecture du terminal.</td><td>42</td></tr><tr><td>2.1</td><td>Performances des processeurs</td><td>46</td></tr><tr><td>2.2</td><td>Données codées en virgule fixe.</td><td>47</td></tr><tr><td>2.3</td><td>Données codées en virgule flottante</td><td>48</td></tr><tr><td>2.4</td><td>Architectures classique et Harvard</td><td>49</td></tr><tr><td>2.5</td><td>Programmation d'un DSP</td><td>51</td></tr><tr><td>2.6</td><td>Comparaison de quelques processeurs.</td><td>52</td></tr><tr><td>2.7</td><td>Structure d'un FPGA type Virtex Xilinx.</td><td>54</td></tr><tr><td>2.8</td><td>Bloc DSP chez Altera.</td><td>56</td></tr><tr><td>2.9</td><td>Réseau de Pétri d'une application multi-tâches synchronisées par sémaphore.</td><td>64</td></tr><tr><td>2.10</td><td>Méthodologie MCSE.</td><td>70</td></tr><tr><td>2.11</td><td>Environnement de Développement Pegasus.</td><td>72</td></tr><tr><td>2.12</td><td>Application de prévisions météorologiques développée avec AVS.</td><td>74</td></tr><tr><td>2.13</td><td>Environnement de développement AVS.</td><td>74</td></tr><tr><td>2.14</td><td>Définition d'un nouveau module sous AVS.</td><td>75</td></tr><tr><td>2.15</td><td>Graphe d'algorithme de SynDEx V6.</td><td>76</td></tr><tr><td>2.16</td><td>Graphe d'architecture de SynDEx V6.</td><td>77</td></tr><tr><td>2.17</td><td>Adéquation SynDEx V6.</td><td>78</td></tr></table>
<table>
  <tbody>
    <tr>
      <td>2.18</td>
      <td>Utilisation de SynDEx</td>
      <td>79</td>
    </tr>
    <tr>
      <td>2.19</td>
      <td>Méthodologie AVS/SynDEx.</td>
      <td>80</td>
    </tr>
    <tr>
      <td>2.20</td>
      <td>Représentation de l'architecture du FPGA sous SynDEx</td>
      <td>82</td>
    </tr>
    <tr>
      <td>2.21</td>
      <td>Architecture générique d'un processeur</td>
      <td>83</td>
    </tr>
    <tr>
      <td>3.1</td>
      <td>Schéma de principe du DSP Texas Instruments TMS320C40</td>
      <td>88</td>
    </tr>
    <tr>
      <td>3.2</td>
      <td>Architecture de la carte SMT314</td>
      <td>89</td>
    </tr>
    <tr>
      <td>3.3</td>
      <td>Architecture de la carte SMT313</td>
      <td>90</td>
    </tr>
    <tr>
      <td>3.4</td>
      <td>Graphe matériel SynDEx V4 pour la plate-forme multi-C4x</td>
      <td>90</td>
    </tr>
    <tr>
      <td>3.5</td>
      <td>architecture d'un C6x.</td>
      <td>91</td>
    </tr>
    <tr>
      <td>3.6</td>
      <td>Comparaison des temps de calcul de FFT et de convolutions en fonction des mémoires utilisées sur un C6x.</td>
      <td>92</td>
    </tr>
    <tr>
      <td>3.7</td>
      <td>C6x Logique additionnelle pour les communications.</td>
      <td>94</td>
    </tr>
    <tr>
      <td>3.8</td>
      <td>Présentation de la carte smt335</td>
      <td>95</td>
    </tr>
    <tr>
      <td>3.9</td>
      <td>Description de la plate-forme Sundance sous SynDEx V5.2.</td>
      <td>96</td>
    </tr>
    <tr>
      <td>3.10</td>
      <td>Environnement matériel</td>
      <td>96</td>
    </tr>
    <tr>
      <td>3.11</td>
      <td>Description de la plate-forme Pentek sous SynDEx V5.2</td>
      <td>97</td>
    </tr>
    <tr>
      <td>3.12</td>
      <td>opérations réalisées par SynDEx</td>
      <td>99</td>
    </tr>
    <tr>
      <td>3.13</td>
      <td>Réseaux de Pétri synchronisés pour deux processeurs</td>
      <td>100</td>
    </tr>
    <tr>
      <td>3.14</td>
      <td>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)</td>
      <td>102</td>
    </tr>
    <tr>
      <td>3.15</td>
      <td>Organisation du noyau d'exécutif</td>
      <td>103</td>
    </tr>
    <tr>
      <td>3.16</td>
      <td>parallélisme entre calcul et communication.</td>
      <td>104</td>
    </tr>
    <tr>
      <td>3.17</td>
      <td>Machine d'état réalisée pour l'implantation de la séquence de communication.</td>
      <td>107</td>
    </tr>
    <tr>
      <td>3.18</td>
      <td>Description de l'application LAR</td>
      <td>109</td>
    </tr>
    <tr>
      <td>3.19</td>
      <td>Architecture multi-DSP sous SynDEx</td>
      <td>111</td>
    </tr>
    <tr>
      <td>3.20</td>
      <td>Diagramme de temps LAR Schedule sur 1 et 2 DSP</td>
      <td>111</td>
    </tr>
    <tr>
      <td>3.21</td>
      <td>Graphe d'algorithme du démodulateur FM</td>
      <td>112</td>
    </tr>
    <tr>
      <td>3.22</td>
      <td>Diagramme temporel du démodulateur FM</td>
      <td>112</td>
    </tr>
    <tr>
      <td>3.23</td>
      <td>Codeur Mpeg-2 développé sous AVS</td>
      <td>115</td>
    </tr>
    <tr>
      <td>3.24</td>
      <td>Exemple de séquence Mpeg-2 avec l'ordre temporel des images, son ordre de codage et les dépendances associées</td>
      <td>116</td>
    </tr>
    <tr>
      <td>3.25</td>
      <td>Graphe flot de données sans module "Newloop"</td>
      <td>117</td>
    </tr>
    <tr>
      <td>3.26</td>
      <td>Graphe flot de données avec module Newloop</td>
      <td>118</td>
    </tr>
    <tr>
      <td>3.27</td>
      <td>Schéma flot de donné du codeur Mpeg-2 sous Syndex.</td>
      <td>119</td>
    </tr>
    <tr>
      <td>3.28</td>
      <td>Diagramme de temps dans le cas monoprocesseur</td>
      <td>120</td>
    </tr>
    <tr>
      <td>3.29</td>
      <td>Division des opérations d'estimation de mouvement en trois pour un parallélisme de données</td>
      <td>120</td>
    </tr>
    <tr>
      <td>3.30</td>
      <td>Diagramme de temps pour une architecture multi-C40</td>
      <td>121</td>
    </tr>
    <tr>
      <td>3.31</td>
      <td>Diagramme de temps optimisé pour une architecture multi-C40</td>
      <td>121</td>
    </tr>
    <tr>
      <td>3.32</td>
      <td>Syntaxe de description du flux codé</td>
      <td>124</td>
    </tr>
    <tr>
      <td>3.33</td>
      <td>Structure logique d'un flux vidéo Mpeg-4</td>
      <td>126</td>
    </tr>
    <tr>
      <td>3.34</td>
      <td>Parallélisme potentiel issu de la structure logique du flux Mpeg-4</td>
      <td>127</td>
    </tr>
    <tr>
      <td>3.35</td>
      <td>Bibliothèques AVS de gestion des flux codés</td>
      <td>127</td>
    </tr>
    <tr>
      <td>3.36</td>
      <td>Exemple de Décodage basé objet Mpeg-4</td>
      <td>129</td>
    </tr>
  </tbody>
</table>
<table><tr><td>3.37</td><td>Voisinage d'un bloc dans le standard Mpeg-4</td><td>129</td></tr><tr><td>3.38</td><td>décodage d'un bloc 8*8 Mpeg-4.</td><td>129</td></tr><tr><td>3.39</td><td>Module de décodage d'un bloc en fonction de son voisinage</td><td>130</td></tr><tr><td>3.40</td><td>Niveaux hiérarchiques supérieurs du décodeur Mpeg-4</td><td>131</td></tr><tr><td>3.41</td><td>Voisinage d'un macrobloc</td><td>132</td></tr><tr><td>3.42</td><td>Niveaux hiérarchiques inférieurs du décodeur Mpeg-4</td><td>133</td></tr><tr><td>3.43</td><td>Mémorisation des données relatives optimisée</td><td>134</td></tr><tr><td>3.44</td><td>Succession des blocs de luminance et de leur voisinage</td><td>134</td></tr><tr><td>3.45</td><td>Mémorisation optimisée du voisinage</td><td>135</td></tr><tr><td>3.46</td><td>Paramètres associés aux entrées/sorties sous AVS</td><td>137</td></tr><tr><td>3.47</td><td>Différence entre les conditionnements sous AVS et SynDEx</td><td>138</td></tr><tr><td>3.48</td><td>Niveaux 1 et 2 de hiérarchie du décodeur.</td><td>140</td></tr><tr><td>3.49</td><td>Temps pour effectuer l'adéquation en fonction du nombre de noeuds du graphe</td><td>142</td></tr><tr><td>3.50</td><td>Positionnement du programme et des données sur le C6201</td><td>143</td></tr><tr><td>3.51</td><td>Gestion des répétitions lors de l'adéquation.</td><td>147</td></tr><tr><td>3.52</td><td>Diagramme temporel SynDEx pour le décodeur Mpeg-4.</td><td>148</td></tr><tr><td>3.53</td><td>Mise en pipeline de l'opération de VLC inverse</td><td>148</td></tr><tr><td>3.54</td><td>Temps d'exécution par macrobloc en fonction du nombre de macroblocs traités par l'adéquation</td><td>149</td></tr><tr><td>3.55</td><td>Taille de l'exécutif généré en fonction du nombre de macroblocs traités par l'adéquation</td><td>150</td></tr><tr><td>3.56</td><td>Taille des données allouées en fonction du nombre de macroblocs traités par l'adéquation</td><td>150</td></tr><tr><td>3.57</td><td>Répétitions prises en compte après l'adéquation.</td><td>151</td></tr></table>
<figure><img src="image_4.png" /></figure>
Liste des tableaux

<table><tr><td>1.1</td><td>Principaux formats de représentation de séquences vidéo.</td><td>15</td></tr><tr><td>1.2</td><td>Exemples de débits usuels.</td><td>16</td></tr><tr><td>1.3</td><td>Définition des profiles et niveaux Mpeg-4.</td><td>33</td></tr><tr><td>2.1</td><td>Principaux fournisseurs de DSP</td><td>52</td></tr><tr><td>2.2</td><td>Quelques outils et leur utilisation dans les phases méthodologiques.</td><td>71</td></tr><tr><td>3.1</td><td>Chronométrages effectués pour l'application LAR sur C6201</td><td>110</td></tr><tr><td>3.2</td><td>Gestion des tampons mémoires par "Newloop"</td><td>117</td></tr><tr><td>3.3</td><td>Chronométrages effectués pour le décodeur Mpeg-4 sur un C6201.</td><td>145</td></tr><tr><td>3.4</td><td>Temps de décodage des flux de test</td><td>146</td></tr></table>
<figure><img src="image_5.png" /></figure>
# Introduction générale

Le développement actuel des applications multimédias est à l'origine de nouveaux modes de communication. La frontière entre les domaines des télécommunications, de l'informatique et de la télévision n'aura d'ailleurs jamais été aussi confuse qu'à ce jour. L'accroissement des échanges de données numériques, quelle que soit leur nature, entre des appareils de plus en plus répandus et de plus en plus hétérogènes introduit de nouveaux enjeux aussi bien sur les systèmes de communication que sur les contenus échangés. Après la parole et le texte, il s'agit maintenant de pouvoir transmettre des documents audio, vidéo ou encore un ensemble constitué de tous ces éléments synchronisés. L'élaboration d'un standard international devient alors une nécessité pour faciliter ces échanges en établissant une représentation compacte des documents. Ce standard, Mpeg-4, se définit comme LE standard pour les communications multimédias.

Comme nous pouvons sans cesse le constater dans la téléphonie mobile, le domaine de l'électronique embarquée est également en pleine mutation. L'utilisation d'applications multimédias est une suite logique dans ce développement et se trouve déjà pris en compte dans l'élaboration du nouveau standard Mpeg-4. Les systèmes temps réels embarqués se caractérisent par des ressources et une puissance de calcul limitées. Mpeg-4 propose des solutions afin de pouvoir limiter le volume des données ainsi que les calculs à effectuer. Néanmoins, les contraintes de temps et le nombre de données restent importants, en particulier pour conserver une bonne qualité des documents audiovisuels échangés. La seule validité fonctionnelle d'une nouvelle méthode de compression d'images n'est absolument pas suffisante pour prévaloir d'une technique réellement utilisable. Elle doit également prouver ses aptitudes temps réel, autrement sa capacité à pouvoir s'exécuter en un temps minimal borné. Dès lors, la première approche consiste à optimiser l'algorithme et à 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 s'avère souvent nécessaire.

Ces observations et le contexte général des recherches ont orienté le groupe Image laboratoire IETR/INSA de Rennes à travailler sur 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 automatique sur des plate-formes parallèles, constituées de composants de même type ou de même famille, mais également sur des plate-formes hétérogènes. Classiquement une partie logicielle s'exécute sur des processeurs standard à laquelle s'associée une partie matérielle pour les calculs les plus critiques. Le principe d'AVS/SynDEx consiste en l'intégration de deux outils industriels et universitaires pour obtenir un processus de
portage et en l'insertion au besoin de passerelles entre ces outils.

Jusqu'ici, la méthodologie AVS/SynDEx a été testée et validée sur des algorithmes travaillant sur des images fixes, sans contraintes de temps fortes. La complexité de ces algorithmes, en terme de calculs et de nombre de données traitées, restait d'autre part relativement faible. L'objectif de nos travaux est d'éprouver la méthodologie sur des applications complexes. Dans ce contexte, l'implantation de services vidéo Mpeg sur plate-formes multi-DSP constitue un défi, surtout si cette implantation se réalise par un seul traiteur d'images et à partir d'une description fonctionnelle haut-niveau des algorithmes.

Le plan retenu pour la présentation de nos travaux est le suivant :

- dans une première partie, nous présenterons le domaine du codage mumérique des images fixes et animées, et particulièrement celles utilisées dans les standards Mpeg-2 et Mpeg-4. Actuellement, le groupe MPEG ayant pour but de remettre à jour Mpeg-4 pour en faire "l'état de l'art" dans le domaine du codage audiovisuel, nous verrons comment il appréhende les futures applications multimédias,

- dans une seconde partie, l'implantation des algorithmes sera étudiée. Tout d'abord, nous présenterons les différentes classes d'unités de calcul qu'il est possible de choisir, et pour chacune d'entre elles les avantages, inconvénients ainsi que les évolutions récentes observées. Nous préciserons les spécificités du domaine temps réel embarqué pour le traitement des images qui nous ont poussés à développer la méthodologie AVS/SynDEx,

- enfin, la troisième et dernière partie présentera les différents développements réalisés pour tester et améliorer la méthodologie AVS/SynDEx, en particulier le développement d'un noyau SynDEx pour la génération automatique de code pour DSP Texas Instruments TMS320C6x, ainsi que les travaux sur un codeur Mpeg-2 et un décodeur Mpeg-4.

Nous conclurons enfin en mettant en avant les contributions de notre travail, ainsi que les quelques pistes à approfondir pour une amélioration du prototypage automatique et optimisé des applications complexes de traitements vidéo comme Mpeg-4.
# Chapitre 1

# Introduction aux techniques de codage et aux standards Mpeg

Images fixes ou vidéos, naturelles ou de synthèse, flux audio, grâce au numérique, on peut envisager de manipuler plusieurs de ces éléments dans une même application et agir sur leurs exécutions de manière interactive. Cette approche implique des ressources et débits importants, ainsi que des techniques de codage performantes. De plus, vu l'inter-nationalisation des réseaux, il est indispensable de normaliser et de sécuriser les échanges des informations qui y transitent. Cela doit permettre de simplifier leur manipulation tant au niveau de l'utilisateur que du concepteur, et ainsi de favoriser le développement des services proposés.

MPEG (Moving Picture Experts Group) est un groupe de travail ISO/IEC chargé du développement des standards de compression, décompression, traitements et représentation de séquences vidéo, audio et de leurs combinaisons. Son enjeu vise à définir un standard pour les flux d'informations, ce qui, implicitement, décrit le schéma général des codeurs et décodeurs de ces flux. Les algorithmes de compression doivent couvrir un grand nombre de fonctionnalités et également s'adapter à une large palette de débits. Ils restent à l'initiative des concepteurs, ce qui permet une évolution des outils sans rendre les normes obsolètes et ainsi faire face à l'évolution rapide des techniques et besoins en la matière.

Depuis 1988, deux standards ont été développés: Mpeg-1 et Mpeg-2. Leur popularité vient d'une part de leurs forts taux de compression mais également de leur caractère universel. Tout en définissant des débits et autres critères, le standard reste générique, c'est-à-dire indépendant de toute application, même si certaines parties de la norme s'appliquent à des supports particuliers, comme le CD vidéo ou CD-i par exemple.

Le standard Mpeg-4, plus qu'un simple standard de codage optimisé pour les transmissions à faibles débits, anticipe sur les nouvelles technologies multimédias basées sur la description d'objets naturels et de synthèse, et sur la combinaison de ces objets formant des scènes audiovisuelles.

Ce chapitre fixe le contexte de l'étude, en présentant les aspects essentiels de la norme Mpeg-4 et en insistant plus particulièrement sur les techniques de codage vidéo. Tout
d'abord, nous allons rappeler les aspects fondamentaux sur lesquels repose Mpeg-4. En-
suite, il s'agira de détailler les aspects hérités du standard Mpeg-2 en termes de codage
vidéo, pour enfin préciser les nouveautés apportées par Mpeg-4. Pour une description
exhaustive du standard Mpeg-4, on pourra se référer à [PE02].

1.1 Généralités

Ce paragraphe de généralités permet d'introduire les objectifs et les différents axes de
travail du groupe MPEG, passés et à venir. Pour mieux appréhender le reste du document,
les caractéristiques des images numériques puis les notions de base du codage numérique
des images sont également présentées.

1.1.1 Généralités sur les images numériques

Une image numérique se représente par une matrice de points appelés pixels. La connaissance des différents formats de représentation et des débits associés permet de comprendre le besoin de codage à l'origine des standards Mpeg-4. De plus, c'est l'occasion de rappeler le vocabulaire lié au domaine, que nous utiliserons par la suite.

1.1.1.1 Formats d'images numériques

Une image numérique se caractérise par son format, c'est à dire une taille, un ra-
fraîchissement et un système de représentation des pixels. Historiquement, plusieurs for-
mats se sont développés en parallèle. Nous allons présenter ici les plus répandus et les
définitions de base.

Le Rafraîchissement

C'est le nombre d'images par seconde. Il existe deux systèmes : US : 30 Hz et EU : 25 Hz

La taille

La taille d'une image fixe est le nombre de pixels qui la constitue, sous forme d'une
matrice à 2 dimensions. Le tableau 1.1 présente les formats les plus courants. On notera
dans ce tableau que les rafraîchissements peuvent être donnés pour des séquences P (pour
"Progressive scanning") ou pour des séquences I (pour "Interlaced scanning"). Dans le
premier cas, l'acquisition des images se fait simultanément sur toutes les lignes, alors que
dans le second, elle se réalise sur l'ensemble des lignes paires puis impaires.)

Représentation des pixels

Les pixels peuvent se représenter de plusieurs manières. Dans une image monochrome
ou dite en "noir et blanc", un pixel possède la plupart du temps 256 niveaux de gris (et
correspond donc à un octet). Le niveau 0 code le noir et le niveau 255 le blanc. Les niveaux
intermédiaires sont utilisés pour les différents niveaux de gris. Une image couleur est plus
complexe et nécessite trois composantes. Il existe deux systèmes :

- R:V:B: un pixel de couleur est la somme des trois composantes Rouge Verte et Bleue. Ce format est uniquement utilisé pour l'affichage.
<table><caption>TAB. 1.1 – *Principaux formats de représentation de séquences vidéo.*</caption><thead><tr><th>Format</th><th>Taille</th><th>Rafraîchissement</th></tr></thead><tbody><tr><td>CIF</td><td>352×288</td><td>25 ou 30 Hz</td></tr><tr><td>QCIF</td><td>176×144</td><td>25 ou 30 Hz</td></tr><tr><td>SIF</td><td>352×240</td><td>30 Hz</td></tr><tr><td>PAL, SECAM</td><td>720×576</td><td>25 Hz</td></tr><tr><td>NTSC</td><td>720×486</td><td>30 Hz</td></tr><tr><td>TV numérique</td><td>720×625</td><td>25 ou 30 Hz</td></tr><tr><td>TVHD</td><td>1920*1152 (16:9)<br>1280*720 (16:9)<br>704*480 (16:9 ou 4:3)<br>640*480 (4:3)</td><td>60I, 30P, 24P<br>60P, 30P, 24P<br>60P, 60I, 30P, 24P<br>60P, 60I, 30P, 24P</td></tr></tbody></table>

- **Y:Cb:Cr**: on décompose la couleur en la somme de la luminance (Y) et de deux composantes permettant de retrouver la couleur : les chrominances Cb et Cr. On peut également noter les chrominances U et V.

La représentation de la couleur avec une composante de luminance est utilisée dans tous les systèmes audiovisuels car l'utilisation de cette composante permet de reconstruire une image "noir et blanc", mais aussi parce que les propriétés statistiques y sont plus facilement exploitables. Historiquement, cela a permis de diffuser des images en couleur, tout assurant la compatibilité avec les anciens postes de télévision noir et blanc.

Pour la représentation des composantes de couleur, on associe un code sur un octet pour chaque composante. En fait, l'oeil humain s'avère plus sensible dans l'espace des luminances que dans celui des chrominances. De ce fait, il est possible de sous-échantillonner la chrominance. On dispose de 3 formats courants :

- **4:4:4**: aucun sous-échantillonnage n'est effectué. Un pixel est représenté par trois octets, un pour chacune des composantes.

- **4:2:2**: le sous-échantillonnage consiste à ne conserver qu'une ligne sur deux pour les coefficients de chrominances. C'est un sous-échantillonnage horizontal. Un pixel est codé en moyenne sur 2 octets.

- **4:2:0**: le sous-échantillonnage est horizontal et vertical. Un pixel est codé en moyenne sur 1.5 octet.

### 1.1.1.2 Débits de séquences vidéo

Le format d'une image implique un débit de la source. Par exemple, pour une séquence TV numérique à 30Hz au format 4:2:2 :

- 2 octets, soit 16 bits, par pixels.

- 1920×1152 pixels par image.

- 30 images par secondes.

Le débit de cette source est 216 Mbits/s (16×1920×1152×30=216×10exp(6)). Pour une séquence QCIF (Fig. 1.1) 4:2:2 à 30Hz, on obtient 9 Mbits/s. Le tableau 1.2 fournit
des ordres de grandeur de débits sur différents supports de transmission et de stockage d'information.

<table><caption>TAB. 1.2 – *Exemples de débits usuels.*</caption><thead><tr><td>Support</td><td>Débit</td></tr></thead><tbody><tr><td>Téléphone portable (GSM)</td><td>9.6 Kbits/s</td></tr><tr><td>RTC</td><td>20 à 56.6 Kbits/s</td></tr><tr><td>RNIS</td><td>K*64 Kbits/s<br>Jusqu'à 2 Mbits/s</td></tr><tr><td>CDROM</td><td>1.2 Mbits/s</td></tr><tr><td>ADSL</td><td>4 à 8 Mbits/s</td></tr><tr><td>DVD</td><td>4.6 Mbits/s</td></tr><tr><td>Fibre optique</td><td>140 Mbits/s</td></tr></tbody></table>

Pour diminuer le débit nécessaire par image et ainsi ne pas encombrer les réseaux et accélérer les transferts, on recourt à la compression des images (codage) dont le but est de diminuer le nombre de données par image.

Les méthodes de codage sont parfois insuffisantes pour les applications à bas débit, il est alors nécessaire de changer le format des images (sous-échantillonnage spatial), de diminuer leurs dimensions ou d'effectuer un sous-échantillonnage temporel. On peut prendre l'exemple de la visiophonie. Suivant la capacité du réseau utilisé et/ou son encombrement, on adapte le nombre d'images transmises (classiquement, entre 5 à 15 images par seconde) pour atteindre les débits classiques de 20 Kbits/s sur une ligne RTC, et 32, 64 ou 128 Kbits/s sur RNIS. Ceci ne va pas sans une dégradation de la qualité : les images ont une faible résolution, des défauts et ne sont pas forcément fluides.

### 1.1.2 Compression d'images fixes

Le codage est donc indispensable pour toute application manipulant des images numériques. Nous allons donc présenter les techniques de compression usuelles pour images fixes, qui seront reprises plus tard dans le contexte de documents vidéo.

#### 1.1.2.1 Principes

Le codage a pour but de réduire l'espace mémoire pris par une image tant pour son stockage que pour ses transferts, et cela en essayant autant que possible de ne pas altérer sa qualité. Pour représenter une image, il faut afficher chaque pixel. Mais un codage de chaque composante de chaque pixel reste peu performant. Le codage peut travailler sur trois axes distincts :

- **La redondance interpixels.** On peut faire une bonne approximation de la valeur d'un pixel à l'aide des pixels voisins spatialement ou temporellement. De ce fait, le format utilisé pour la visualisation des images n'est pas optimal pour le stockage et la transmission d'image. On peut coder les différences entre les pixels ou effectuer une transformation qui a pour but de concentrer l'énergie des pixels dans un nombre
réduit de coefficients. L'essentiel est d'obtenir les coefficients des plus décorrélés possibles.

- Les caractéristiques psychovisuelles. L'oeil possède des limites de perception. Ainsi le seuil de perception des erreurs de reconstruction se verra plus élevée dans les contours de l'image permettant alors une approximation plus grossière.

- Les propriétés statistiques des données à coder. On veut utiliser des mots de code à longueur variable permettant de prendre en compte les caractéristiques statistiques de l'image.

Les solutions de codage sont variées et il convient de choisir la technique la mieux adaptée à l'image à coder. Pour cela, nous allons maintenant présenter quelques techniques de codage usuelles.

### 1.1.2.2 Techniques usuelles de codage

On distingue deux grands types de codage: les codages avec perte ou sans perte. Le codage est dit sans perte si l'on peut reconstruire intégralement l'image originale à partir de l'image codée. Le codage avec perte n'assurera quant à lui qu'une reconstruction approchée de l'image. Nous allons présenter tout d'abord la quantification, caractéristique des codages avec perte, puis les codages statistiques, les transformations et le MICD qui restent des techniques sans pertes lorsque non utilisées avec une phase de quantification.

- La quantification. Cette technique de base s'associe au codage avec perte. Il s'agit de diminuer les niveaux de représentation des pixels d'une image. Si une valeur est codée sur N bits, la valeur sera comprise entre 0 et (2$^{N}$ - 1). Le fait d'enlever un bit pour le codage de cette valeur va diminuer sa taille de représentation, mais induire une représentation plus grossière (division par deux du nombre de niveaux) et donc probablement une perte de qualité.

- Le codage statistique. On utilise la distribution de probabilité des pixels ou coefficients pour lui associer un code à longueur variable. Le principe est de donner aux coefficients les plus probables les codes les plus courts. On trouve par exemple le codage d'Huffman [Huf51] et le codage arithmétique [Ris76] qui n'attribue pas un code à chaque symbole mais un code pour un ensemble de symboles. Le codage Mpeg utilise un codage statistique appelé VLC (Variable Length Coding). Le codage VLC, proche du codage de Huffman, utilise des tables à "entropie contrainte", c'est-à-dire non-téléchargeables et optimisées pour un débit limité.

- Les transformations usuelles, DCT. Ces transformations linéaires ont pour but de diminuer les redondances interpixels. Il est possible de trouver un mode de représentation de l'image évitant de définir une valeur en chacun de ces points. Le codage est alors réalisé à partir de ce nouveau mode de représentation. Les transformations permettent de décorréler l'information présente dans l'image, et également de définir les informations pertinentes pour un codage avec perte.
Il faut noter que ce n'est pas la transformation qui réalise la compression mais uniquement les opérations possibles ultérieurement sur les coefficients transformés. Par exemple, l'élimination des coefficients chargés de l'information sur les hautes fréquences ou la quantification des coefficients.

On peut citer différentes transformations :

- Karhunen-Loeve (KLT),

- Fourier (FFT),

- cosinus discret (DCT),

- Walsh,

- Hadamard,

- ou encore les ondelettes.

La transformation KLT est optimale : elle offre des coefficients totalement décorrélés et donc une forte concentration de l'information. La transformation KLT possède cependant des inconvénients : il n'existe pas d'algorithmme rapide de calcul des coefficients et elle nécessite de connaître quelques propriétés statistiques de l'image (matrice d'auto-corrélation). Elle reste peu utilisée du fait de la lourdeur des calculs nécessaires.

La DCT est asymptotiquement équivalente à la KLT pour un signal stationnaire de Gauss-Markov d'ordre 1 [Leh01] (les quelques premiers coefficients DCT sont équivalents aux valeurs issues de la KLT fournissant la variance [CS998]). De plus, la DCT possède des algorithmes de calcul rapides. C'est la transformation utilisée dans les standards Mpeg.

Plus de formellement, soit x(n) la valeur d'un pixel du bloc et X(n) le coefficient transformé correspondant, les relations entre x(n) et X(n) sont données par les équations suivantes pour un bloc de pixels de taille N×N :

$$X(n) = \sqrt{\frac{2}{N}} \sum_{k=0}^{N-1} v(n)x(k) \cos \frac{\pi n(k + \frac{1}{2})}{N} \quad (1.1)$$

$$x(n) = \sqrt{\frac{2}{N}} \sum_{k=0}^{N-1} v(n)X(k) \cos \frac{\pi n(k + \frac{1}{2})}{N} \quad (1.2)$$

$$v(n) = \begin{cases} \frac{1}{\sqrt{2}} & \text{si } k = 0 \\ 1 & \text{sinon} \end{cases} \quad (1.3)$$

la relation 1.1 constitue le calcul dit de DCT directe, ou simplement de DCT, et la relation 1.2 le calcul de la DCT inverse, également appelé IDCT.

En compression, la transformation opère souvent sur des blocs d'image. En effet, cela réduit la charge des calculs par rapport au calcul sur l'image entière, et permet une meilleure homogénéité statistique des pixels observés. Dans le cas de Mpeg, on utilise souvent la DCT sur des blocs de taille fixe 8×8. Chaque bloc est transformé, codé puis émis de manière séparée. Si on utilise un codage avec perte, les blocs re-construits seront différents des originaux, les erreurs dépendront des blocs traités. Sur l'image reconstruite, les bords des blocs utilisés tendront à être visibles du fait des discontinuités des erreurs entre les blocs. Ce phénomène, appelé effet de blocs,
constitue souvent le principal inconvénient de cette technique.

Les transformations en ondelettes s'avèrent être très efficaces. Elles travaillent sur l'image dans sa globalité, ce qui limite les effets de blocs observés avec une transformation basée bloc. Les transformations en ondelettes sont adaptées au codage progressif d'une image et font leur apparition dans les normes Jpeg-2000 et Mpeg-4, contrairement aux transformations des standards antérieurs qui utilisaient uniquement la DCT.

- Le MICD : Modulation d'Impulsion par Codage Différentiel. C'est une méthode de codage très répandue, appelée DPCM (Differential Pulse Code Modulation) en anglais. Cette technique consiste à réaliser une prédiction à base d'une combinaison linéaire des valeurs des points dans le voisinage du point à coder. On ne code que l'erreur de prédiction. Le gain en compression par cette technique est obtenu par le fait que l'erreur de prédiction à coder possède statistiquement une faible amplitude. Plus la prédiction est bonne, moins l'information à transmettre sera conséquente, et donc plus le débit de l'information restera faible. Une version adaptative a été développée : l'ADPCM. Cette version utilise différentes combinaisons linéaires pour une prédiction suivant le contexte. L'utilisation d'un voisinage causal de seulement trois points permet a cette technique d'être l'une des plus performantes parmi les techniques prédictives.

### 1.1.3 Normes Mpeg

Le groupe MPEG développe des standards de compression vidéo. Tout comme les normes JPEG, pour le codage d'images fixes, JBIG, pour le codage d'images binaires, et MHEG, nouveau standard software de manipulation des données multimédia/hypermédia dans les applications, plates-formes et services, MPEG fait partie du comité ISO (International Standards Organisation). Fondé en 1988, le groupe MPEG a travaillé et travaille sur différents standards indépendants et qui répondent à des contraintes différentes :

<figure><img src="image_6.png" /><figcaption>FIG. 1.1 – Schéma global d'un décodeur Mpeg-1.</figcaption></figure>

#### Mpeg-1

C'est un standard pour la mise en mémoire de documents audiovisuels compressés sur CD-rom, Vidéo-CD ou Cdi, utilisé également pour transmettre des vidéos sur les réseaux
téléphoniques numériques comme ADSL, kiosques vidéo, ou pour la transmission de documents audio sur Internet. C'est le premier standard mis en place par MPEG (Fig. 1.1). Mpeg-1 est générique. Seul le schéma de décodage est défini. Mpeg-1 est basé sur un codage DCT/DPCM avec compensation de mouvement, tout comme les standards H.261 ou CCIR Rec. 723. Nous aurons l'occasion de détailler cette technique dans ce premier chapitre. Mpeg-1 permet un accès aléatoire aux différentes données numériques stockées et est figé depuis 1992.

### Mpeg-2

Mpeg-2 est un standard adapté à la télévision numérique. Le but initial, en 1990, était de proposer une technique pour le codage d'images télévisées au format CCIR (que nous présenterons plus tard) permettant des débits inférieurs à 10 Mbit/s. Mpeg-2 n'est pas "meilleur" que Mpeg-1, il est plus adapté pour des documents audiovisuels de meilleure qualité et nécessitant des plus forts débits (entre 3 et 10 Mbits/s). Son domaine d'application s'est ensuite élargi à la télévision numérique haute définition (HDTV) et au DVD. Inspirée de Mpeg-1, cette norme prend en compte l'entrelacement de séquences vidéo et/ou audio et permet des interactions entre l'utilisateur et la source. Mpeg-2 est figé depuis 1994.

### Mpeg-3

Initialement prévu pour des images de taille importante et aux flux compris entre 20 et 40 Mbits/s, afin de couvrir les besoins de la télévision numérique haute définition, Mpeg-3 a finalement été intégré dans Mpeg-2.

### Mpeg-4

Mpeg-4 est un standard prenant en compte les besoins actuels et futurs des applications multimédias. Mpeg-4 fournit des solutions aux problèmes suivants :

- **Indépendance du réseau et robustesse en milieu bruité.** En effet, les données devront transiter par des réseaux hétérogènes, en particulier des réseaux à forts taux d'erreur comme pour le GSM. Même si le standard est indépendant du réseau utilisé, les algorithmes de codage doivent permettre de mettre en œuvre des techniques minimisant les effets des erreurs engendrées par le bruit.

- **Haut niveau d'intéractivité.** Les futures applications multimédia nécessiteront cette intéractivité afin de répondre au mieux aux désirs de l'utilisateur. En plus des actions courantes sur les séquences vidéo et/ou audio, comme l'avance/retour rapide, l'utilisateur devra pouvoir manipuler le "contenu" des données pour rendre leur affichage et leur stockage flexibles.

- **Codage de données naturelles et de synthèse.** Les synthèses vocale et d'image devront pouvoir s'intégrer de manière harmonieuse aux données audiovisuelles classiques.

- **Haut niveau de compression,** ce qui signifie à la fois minimisation de l'espace pris par les données lors du stockage et de la transmission, mais aussi une bonne qualité de reconstruction. Cette notion reste particulièrement importante pour les
débits inférieurs à 64 Kbits/s.

Les débits pris en compte dans Mpeg-4 vont de 5-64 Kbits/s pour les applications destinées aux mobiles, jusqu'à 2 Mbits/s pour celles destinées à la télévision ou au cinéma. Mpeg-4 est toujours en cours de développement. La première version appelée VM (Verification model) date de janvier 1996. Le VM reste très général et permet de définir les spécificités communes aux algorithmes, comme le format d'entrée/sortie des données non codées, ou le format du flux de données codées. Lors des réunions MPEG, des CE (Core Experiments) sont proposés pour améliorer le VM. En Octobre 1998, une première version du standard a été figée, mais les travaux continuent et les versions sont mises à jour tous les ans, en conservant les données des précédentes versions et en y ajoutant des corrections, des précisions ou de nouvelles techniques (Fig. 1.2). Le but est de rester en phase avec les techniques toujours en évolution.

<figure><img src="image_7.png" /><figcaption>FIG. 1.2 – Organisation des versions dans le standard Mpeg-4</figcaption></figure>

## Mpeg-7

Mpeg-7 est un standard d'indexation. De plus en plus de documents sont stockés sur des supports numériques, que ce soient des documents informatiques, des images, films, livres ou encore musiques. Il devient donc important de se pencher sur le problème que cela pose : comment classer et retrouver de manière rapide un document. Mpeg-7 y travaille ainsi que sur la représentation du contenu d'un document permettant la recherche par thème. Le principe associe un moteur d'instanciation automatique à une base de données. Ce moteur d'instanciation crée la description des éléments de la base selon les spécifications Mpeg-7. Lorsqu'un moteur de recherche veut consulter la base de données, il dialogue avec le moteur d'instanciations et accède à des descripteurs classés de manière hiérarchique et renseignant sur les textures, formes, mouvements, localisation, couleurs, ou encore sur les structures de base des documents archivés (structure temporelle, points de vue par exemple). Mpeg-7 donne un cadre standardisé à ces échanges. Pratiquement, avec Mpeg-7, il sera possible de récupérer des données multimédias et d'identifier celles qui peuvent effectivement être transmises et affichées, compte tenu de la bande passante du réseau et des caractéristiques du terminal. L'impact devrait être particulièrement significatif dans le domaine des moteurs de recherche, encore inaptes à identifier les contenus audiovisuels.

## Mpeg-21

Mpeg-21 est un standard de codage et de compression pour permettre une utilisation
transparente et enrichie de ressources multimédias dans une vaste gamme de réseaux (télévision numérique hertzienne, par satellite ou par câble, Internet à haut-débit, téléphonie sans fil, etc.) et d'appareils exploités par différents groupes. Il permettra l'intégration des processus requis pour créer, manipuler, utiliser, gérer et diffuser des fichiers multimédias. La norme comprend des éléments qui appuient l'identification et la description de ressources numériques, le traitement et l'utilisation du contenu, la gestion et la protection de la propriété intellectuelle.

Basés sur des techniques de compression d'images fixes, la compression vidéo a pour particularité d'utiliser les redondances entre les différentes images d'une séquence. Comme les niveaux de qualité et l'utilisation de vidéo et d'images fixes sont différents, des standards spécifiques ont été développés. Nous allons donc présenter maintenant le standard Mpeg-2 et les principales techniques utilisées par ce standard.

## 1.2 MPEG-2: standard de codage vidéo

### 1.2.1 Introduction

Il ne s'agit pas dans cette partie de décrire l'ensemble du standard Mpeg-2, mais la technique de codage des vidéos naturelles, point essentiel dans Mpeg-2 et réutilisé dans de nombreux algorithmes Mpeg-4. Basé sur l'utilisation combinée des différentes techniques précédemment présentées, Mpeg-2 est depuis maintenant quelques années devenu une référence en termes de codage de vidéos.

### 1.2.2 Décomposition de la séquence vidéo

Contrairement à la norme JPEG où les images d'une vidéo sont traitées indépendamment les unes des autres, Mpeg traite une séquence en la découpant en tronçons d'images appelée **GOP (Group Of Picture)**. Cela permet d'améliorer la compression en prenant en compte la corrélation temporelle.

<figure><img src="image_8.png" /><figcaption>FIG. 1.3 – *Enchaînement des images dans un GOP.*</figcaption></figure>

Un GOP est constitué d'une suite d'images codées selon trois méthodes : codage intra-
image (I-frame), prédictif (P-frame) et bidirectionnel (B-frame). La figure 1.3) montre les 16 premières images d'une séquence vidéo et leur type (I, P ou B). L'ordre de codage est fixe, avec une image I en début de GOP, puis un motif répétitif de deux images B et une image P jusqu'à la fin du GOP. La fréquence des images I, c'est-à-dire la taille du GOP, est variable. La sélection constitue un paramètre du codage. Les images I sont indispensables pour que le décodeur puisse commencer la chaîne de prédiction.

Au sein d'une image, l'ensemble des opérations opère sur des blocs 16×16 appelés macroblocs (Fig 1.4). Les pixels de la source analogique sont échantillonnés, quantifiés, codés et rangés dans les macroblocs. Un macrobloc possède donc 256 valeurs pour la luminance et 64 pour chaque élément de la chrominance (Cb et Cr) dans le format 4:2:0 généralement utilisé, soit 384 valeurs pour 256 pixels. Le ou les macroblocs contigus sur une même ligne sont regroupés en tranches ("slices"). Les tranches permettent de limiter la propagation des erreurs en autorisant le décodeur à se synchroniser sur le début de chaque tranche. Les erreurs commises se limitent à la tranche décodée.

Les macroblocs peuvent être codés de différentes manières que l'on divise en deux catégories : codage intra et codage prédictif, qui font l'objet des deux parties suivantes.

<figure><img src="image_9.png" /><figcaption>FIG. 1.4 – *Un macrobloc au format 4:2:0.*</figcaption></figure>

### 1.2.3 Codage intra-image

C'est un codage similaire à la norme JPEG et qui permet de réduire les redondances spatiales, c'est-à-dire les similarités entre pixels voisins dans une image. On code la première image d'un GOP indépendamment des images suivantes. Les macroblocs 16×16 sont décomposés en blocs 8×8 puis traités suivant le déroulement des différentes opérations montré figure 1.5 :

A partir de l'image initiale, on découpe des blocs de taille 8×8 auxquels on applique une transformation DCT. Les coefficients non quantifiés résultant de la DCT sont codés sur 11 bits. Suivant la précision requise par l'application, ces coefficients seront réduits aux 8, 9 ou 10 bits de poids forts. Une seconde quantification est alors opérée avec une matrice de quantification fixe (qui n'est donc pas obligatoirement à transmettre). Cela permet de négliger les informations dont l'influence sur la perception de l'image sera faible. Les hautes fréquences, par exemple, ont des pas de quantification très supérieurs aux basses
<figure><img src="image_10.png" /><figcaption>FIG. 1.5 – Schéma global du codage intra-image.</figcaption></figure>

fréquences.

Deux types de matrices sont utilisés : l'un pour les macroblocs codés en intra, et l'autre pour les macroblocs non codés en intra. Pour ces deux types, il existe des matrices par défaut mais il est possible de transmettre des matrices de quantification spécifiques.

On obtient donc une suite de blocks 2D 8×8 à l'entrée du Scanner, qui fournit une séquence 1D en rangeant les valeurs des coefficients dans l'un des ordres de la figure 1.6. Ceci permet de traiter la séquence 1D des coefficients en commençant par les basses fréquences et de continuer dans l'ordre des fréquences croissantes. Les plus fortes fréquences étant d'un impact psychovisuel moins important, il est possible de les traiter différemment.

<figure><img src="image_11.png" /><figcaption>FIG. 1.6 – Zig-Zag scan et alternate scan.</figcaption></figure>

L'étape suivante est d'une part un codage par plage permettant de coder les suites de coefficients de valeur nulle, et d'autre part un codage statistique des autres coefficients. Cet ensemble de techniques de codage est dénommé VLC (Variable Length Coding) dans les standards Mpeg.
### 1.2.4 Codage prédictif

Alors que le codage intra permet de réduire les redondances spatiales, le codage prédictif utilise quant à lui les similarités entre les images consécutives dans la vidéo pour réduire les redondances temporelles. On va donc prédire les valeurs d'un macrobloc à l'aide de l'image *I* ou *P* précédente (codage inter-images).

Comme première possibilité, au lieu de coder les valeurs d'un macrobloc, on code la différence entre ses valeurs et une prédiction faite à partir du macrobloc de même position dans l'image précédente (Fig. 1.7). Ceci doit permettre de coder des valeurs plus faibles en dynamique, ce qui diminue la taille des données à transmettre. Il est également possible de ne pas coder un macrobloc (macrobloc dit "skipped"). Dans ce cas, le macrobloc correspondant dans l'image précédente est directement utilisé pour la reconstruction de l'image courante.

<figure><img src="image_12.png" /><figcaption>FIG. 1.7 – Codage prédictif simple.</figcaption></figure>

Une seconde et meilleure possibilité permettant de diminuer la dynamique de l'erreur de prédiction de chaque pixel, est de prédire un macrobloc non pas à partir du macrobloc de même position dans l'image précédente, mais à partir du macrobloc de l'image précédente le plus "ressemblant" au macrobloc à coder. La ressemblance est testée et obtenue par une compensation de mouvement de type translation opérée sur les différents macroblocs candidats dans l'image précédente. C'est la compensation de mouvement présentée sur la figure 1.8. On code alors la différence entre ces deux macroblocs. Il faut noter que le mouvement de translation donné n'est généralement pas le déplacement réel du bloc considéré.

Dans les codages prédictifs avec compensation de mouvements, on doit transmettre deux informations : le vecteur de mouvement du macrobloc et les erreurs de prédictions. Ces dernières vont de plus être codées avec un schéma de codage similaire à celui des images intra (Fig. 1.5) afin de réduire les redondances spatiales.

La prédiction peut être réalisée à partir d'une image qui se situe plus tôt dans la séquence vidéo (*forward prediction*, prédiction avant), mais également à partir d'une image qui se situe plus tard dans la séquence (*backward prediction*, prédiction arrière) ou avec deux images, l'une avant et l'autre après dans la séquence (*bidirectional prediction*). Dans
<figure><img src="image_13.png" /><figcaption>FIG. 1.8 – Codage prédictif avec compensation de mouvement.</figcaption></figure>

le cas de la prédiction bidirectionnelle, on code la différence entre les valeurs à transmettre et la prédiction obtenue par moyenne des deux blocs situés avant et après le bloc à coder. On prend alors en compte la corrélation entre les trois images, ce qui peut donner de meilleures prédictions.

Avec ce type de codage, les fortes variations de mouvement ne seront prises en compte que de manière grossière du fait de la quantification des vecteurs de mouvement, provoquant alors une pixélisation de l'image. Ceci concerne en particulier les scènes de type explosion, véhicules en mouvements. Ce phénomène peut se réduire par un filtrage approprié.

### 1.2.5 Schéma global

Mpeg-2 est basé sur ces deux techniques que sont la transformation DCT, pour la diminution des redondances spatiales, et la prédiction temporelle avec compensation de mouvement, pour les redondances temporelles. Le schéma global de codage utilisé est donné figure 1.9.

Dans une image de type I, tous les macroblocs sont codés en Intra, comme c'est le cas des images Jpeg. Par contre, dans une image de type P, les macroblocs sont soit codés en intra, ou en prédictif avec une prédiction avant, et ce à partir d'une image de type I ou P. Enfin, les images de type B sont constituées de macroblocs reconstruits soit par codage intra, soit en prédictif avec une prédiction avant, arrière, ou encore une prédiction bidirectionnelle. Cela implique un ordre de codage et de transmission différent de l'ordre d'affichage. A noter également qu'il ne faut pas utiliser une image B pour prédire une image future.

La corrélation entre les pixels dans les images prédites et compensées en mouvement, est faible en comparaison de la corrélation des pixels des images codées en Intra. L'utilisation des codages prédictifs permet donc d'améliorer la compression en prenant en compte la corrélation temporelle. On pourrait émettre une unique image I au début de la séquence vidéo et reconstruire le reste de la séquence grâce à des images P et B. La compression serait meilleure qu'en découpant la séquence en GOP. Par contre, il serait impossible de commencer le décodage à partir du milieu de la séquence. Un GOP est constitué d'environ 10 à 15 images, soit approximativement 0.5 seconde de film. On peut commencer
<figure><img src="image_14.png" /><figcaption>FIG. 1.9 – Schéma de codage prédictif avec compensation de mouvement.</figcaption></figure>

le décodage au début de chaque GOP, ce qui permet l'accès aléatoire aux données. La décomposition de vidéos en GOP permet également les déplacements avant et arrière rapides.

Mpeg-2 est, grâce à ces techniques, bien adapté au codage de séquences vidéo naturelles pour leur stockage ou leur transfert. La manière d'organiser le transport des bits codés, c'est-à-dire la partie "système" de la norme, permet, entre autres, l'entrelacement de plusieurs séquences vidéo dans un même flux de bits ainsi la prise en compte des actions de l'utilisateur. Cette partie système à été reprise et enrichie pour Mpeg-4, puisqu'il s'agit d'élargir la boite à outils pour une nouvelle génération d'applications: les applications multimédias.

## 1.3 MPEG-4: standard pour applications multimédias

Mpeg-4 reprend les principes de base décrits dans la présentation de Mpeg-2. Pour le codage de vidéo d'origine naturelle, même si les calculs diffèrent quelque peu, de nombreux points communs existent dans les techniques utilisées. Nous nous attacherons plutôt aux innovations apportées par Mpeg-4. Pour une description détaillée du standard, on pourra se reporter à [PE02].

### 1.3.1 Introduction

Les outils Mpeg-4 ont été élaborés pour des applications précises. C'est pourquoi la description de quelques exemples permet de savoir ce qu'il est envisageable de faire avec une technologie Mpeg-4. D'autres exemples sont fournis dans [JTC99].
### 1.3.1.1 Télévision numérique

L'émission de programmes numériques va révolutionner le monde de la télévision en y introduisant l'intéractivité. Il sera possible, à partir d'un poste de télévision :

- d'accéder à l'information et aux loisirs proposés par l'Internet,

- d'utiliser les messageries électroniques directement sur son poste TV à l'aide d'un clavier sans fil,

- d'accéder à des services commerciaux et bancaires sûrs (home shopping),

- de participer à des jeux télévisés interactifs,

- de bénéficier de films à la demande.

En plus de pouvoir décodeur des flux audio et vidéo Mpeg-4, le système devra pouvoir manipuler ces différents flux, en contrôler l'affichage, proposer une interface à l'utilisateur, contrôler et créer des éléments graphiques, gérer les communications avec le pourvoyeur de services, gérer les droits d'accès, guider l'utilisateur parmi les services proposés, gérer les ressources ainsi que le profil utilisateur. Les données numériques devront contenir les informations nécessaires à la description et au contrôle de scènes. Il faudra également pouvoir télécharger des "applets", petits programmes écrits en Java, que l'on pourra incorporer dans des pages HTML. A l'ouverture de la page HTML, l'applet se téléchargera puis s'exécutera automatiquement.

### 1.3.1.2 DVD: Digital Versatile Disk

Les DVD se caractérisent par leur grande capacité mémoire (4.7 Gbytes) et un faible temps d'accès (environ 100 ms). Il existe des DVD en lecture seule et des DVD en lecture/écriture. Les domaines d'application sont les films interactifs, guides en tout genre (touristiques, historiques), jeux, karaoke sur Internet, interactions avec Internet.

Les films interactifs permettent au spectateur de contrôler l'affichage à l'écran. Un exemple d'utilisation est le contrôle parental permettant de supprimer certaines scènes dans un programme.

Une autre application possible grâce au DVD est le chargement de journaux quotidiens pendant la nuit, lorsque le réseau est peu utilisé. On peut aussi envisager le chargement d'une journée de programme télévisé (excepté les directs bien sûr). Ce type d'utilisation nécessiterait des transmissions très rapides et utilisant une bande passante importante ("wide bandwidth").

### 1.3.1.3 Infotainment

Infotainment est la concatenation en anglais de "information" et de "entertainment" (divertissement). C'est donc une application basée sur le mélange de ces deux domaines. L'infotainment est basé sur les interactions de l'utilisateur et rentre donc parfaitement dans le champ d'action de Mpeg-4. L'exemple type d'infotainment est le guide touristique virtuel constitué des 3 parties suivantes que montre la figure 1.10 :

- La première partie est le cadre principal où l'on trouve information et divertissement. Il est constitué d'un pilier romain, d'un donjon et d'un "vidéodrome". L'utilisateur peut demander plus de renseignements sur l'un de ces éléments, des films
<figure><img src="image_15.png" /><figcaption>FIG. 1.10 – Exemple d'infotainment.</figcaption></figure>

complémentaires lui fourniront des informations sur la ville virtuelle et les points essentiels.

- La seconde partie se trouve dans le vidéodrome (non visible sur la figure 1.10, où l'on trouve un monde virtuel interactif constitué d'objets vidéo. Ces objets sont des chanteurs, danseurs et musiciens que l'utilisateur peut manipuler pour créer une scène virtuelle.

- Enfin, le donjon contient un labyrinthe. C'est un jeu en trois dimensions permettant à des joueurs du monde entier de jouer ensemble dans le même environnement.

Pour résumer, cette application d'infotainment est un mélange d'informations dans le guide touristique, et de divertissements grâce au jeu en trois dimensions du donjon.

### 1.3.1.4 Téléphones portables multimédias

Dans ce contexte, le but est d'avoir un téléphone portable capable de communiquer avec un autre distant par une liaison sans fil. On veut pouvoir échanger des données (carnet d'adresses, notes, images) quelle que soit la position du téléphone, et palier aux limites techniques rencontrées sur les portables, comme les capacités de calcul et/ou de mémoire limitées, ou les difficultés liées aux échanges de données.

Ces applications nécessitent de forts taux de compression, mais également une indépendance vis-à-vis des réseaux (GSM, UMTS, HIPERPLAN ou satellite), une gestion pour optimiser les facteurs coût/rapidité/qualité. Mpeg-4 apporte différents niveaux de codage/décodage permettant d'adapter les échanges en fonction des situations et ainsi d'optimiser les facteurs coût/rapidité/qualité.

## 1.3.2 Organisation de la norme, Profiles@Levels

Mpeg-4 fournit des schémas de décodage divers et variés permettant une décompression efficace des données, mais aussi et surtout indique la manière d'organiser les données codées dans un flux de bits. Un flux Mpeg est formé autour de plusieurs axes formant chacun une partie, chacune de ces parties étant divisées en profiles et levels. Il existe 10 parties :

- Partie 1 : "systems". Le constructeur système donne les informations sur la syn-
chronisation, l'accès aux données, la gestion des buffers pour éviter "underflows" et "overflows", la chronologie des images dans une séquence ou encore la protection des documents.

- Partie 2: "Visual". La partie vidéo de Mpeg-4 spécifie la représentation codée des objets vidéo naturels et de synthèses.

- Partie 3: "Audio". La partie audio de Mpeg-4 spécifie la représentation codée des objets audio naturels et de synthèses.

- Partie 4: "Conformance testing". Cette partie permet de vérifier la conformité d'un codeur ou d'un décodeur Mpeg-4.

- Partie 5: "Reference Software". Ceci correspond à un logiciel ou plusieurs outils décrits dans le standard (de manière normative ou non) sont implantés.

- Partie 6: "DMIF". Le DMIF ("Delivery Multimedia Integration Framework") gère l'accès aux différentes ressources (disques internes, CD-Rom, réseaux) et les échanges avec elle.

- Partie 7: "Optimized Visual Reference Software". Ce logiciel implante des techniques comme l'estimation de mouvements rapide, l'estimation globale de mouvement rapide et la génération de "ICO" que nous définirons ultérieurement.

- Partie 8: "Carriage of Mpeg-4 contents over IP Networks". Il s'agit ici de décrire comment intégrer des contenus Mpeg-4 sur plusieurs protocoles de communications.

- Partie 9: "Reference hardware description". Cette partie propose une description VHLD pour la simulation et la synthèse de certains outils Mpeg-4, à paraître en 2003,

- Partie 10: "Advanced Video Coding (AVC)". La première version de cette partie paraîtra en 2003 et proposera un version Mpeg-4 des outils de codage vidéo très performants du standard H.26L.

Toutes ces ressources doivent fonctionner simultanément ou non et sont étroitement liées dans les processus de multiplexage de l'encodeur et de démultiplexage du décodeur. Nous nous intéresserons principalement à la seconde partie de Mpeg-4.

Mpeg-4 fournit un nombre très important d'outils permettant de coder les différents objets audiovisuels. Toutes les applications n'ont pas à manipuler l'ensemble de ces outils, et ne disposent pas des mêmes besoins en termes de qualité. En effet, il n'est pas utile d'implanter un codeur vidéo pour la diffusion de programmes radios, comme il n'est pas nécessaire de définir un codeur sans perte d'information pour du bas débit. Afin de permettre une implantation du standard, comme pour Mpeg-2, des sous-ensembles de ces outils ont été créés dans chacun des constructeurs (système, audio, vidéo et DMIF), sous-ensembles appelés profils ("Profiles") [Koe00]. Dans chaque profil, un ou plusieurs niveaux ("levels") sont définis. Une combinaison profil@niveau permet de définir un codeur simple, compatible avec les autres codeurs et décodeurs Mpeg-4 développés pour le même profil@niveau. Le concepteur doit choisir un ou plusieurs de ces profils en fonction de son application.

Il existe 5 profils :

- Profil audio.
- Profil visuel.

- Profil graphique.

- Profil de description de scène.

- Profil de description d'objets.

Leur description est détaillée dans le tableau 1.3.

<table><thead><tr><td>Type de Profils</td><td>Profils</td><td>Types d'objets concernés</td><td>Exemples d'applications visés</td></tr></thead><tbody><tr><td rowspan="7">Visual Profile</td><td>Simple</td><td>Images naturelles rectangulaires classiques</td><td>Applications à faibles débits type réseaux de mobiles</td></tr><tr><td>Simple Scalable</td><td>Images naturelles rectangulaires à plusieurs niveaux de qualités spatiales et temporelles</td><td>Applications à QoS variable de type Internet ou décodeurs softwares</td></tr><tr><td>Core</td><td>Images naturelles à plusieurs niveaux de qualité spatiale et de formes arbitraires</td><td>Applications à faible niveau d'intéractivité</td></tr><tr><td>Main</td><td>Idem Core Profile avec objets entrelacés, semi-transparentes et sprite</td><td>Applications DVD ou émissions interactives ou nécessitant une bonne qualité</td></tr><tr><td>N-bits</td><td>Idem Core Profile avec des pixels codés entre 4 et 12 bits</td><td>Applications de surveillance</td></tr><tr><td>Simple Facial Animation</td><td>Images de synthèse pour l'animation de visage</td><td>Applications avec des données audiovisuelles endommagées</td></tr><tr><td>Scalable Texture</td><td>Textures d'images fixes sur plusieurs niveaux de qualité</td><td>Ajout de textures dans des jeux, appareils photos numériques haute résolution</td></tr><tr><td rowspan="2">Basic Animated 2D Texture</td><td>Animation de textures et de visages simples avec plusieurs niveaux de qualité</td><td></td></tr><tr><td>Hybrid</td><td>Décodage de formes arbitraires, objets vidéo à fréquence variable, objets vidéo de synthèse ou hybrides, figés ou animés</td><td>Applications multimédia complexes</td></tr></tbody></table>

Suite page suivante
<table><thead><tr><th>Type de Profils</th><th>Profils</th><th>Types d'objets concernés</th><th>Exemples d'applications visés</th></tr></thead><tbody><tr><td rowspan="4">Audio Profile</td><td>Speech</td><td>HVXC et CELP: codeurs de parole très faible débit et faible débit, interface permettant la synthèse vocale à partir de texte</td><td>Synthèse vocale</td></tr><tr><td>Synthesis</td><td>SAOL, synthèse vocale</td><td>Synthèse vocale et d'une grande variété de sons et musiques à faible débit</td></tr><tr><td>Scalable</td><td>Superset du speech profile</td><td>Synthèse vocale et de musique à plusieurs degrés de qualité pour l'internet ou le NADIB</td></tr><tr><td>Main</td><td>Superset des autres Profiles Audio</td><td>Applications complexes à base de sons naturels et de synthèse</td></tr><tr><td rowspan="3">Graphic Profile (partie système de Mpeg-4)</td><td>Simple 2D</td><td>BIFS permettant de gérer un ou plusieurs objets graphiques</td><td></td></tr><tr><td>Complete 2D</td><td>Fonctionnalités plus importantes et permettant de gérer du texte et des objets vidéo</td><td></td></tr><tr><td>Complete</td><td>Applications complexes comme des mondes virtuels nécessitant un haut degré de réalisme</td><td></td></tr><tr><td rowspan="2">Scene Description Profile (partie système de Mpeg-4)</td><td>Audio</td><td>BIFS pour les applications avec uniquement des objets audio (radios numériques par exemple)</td><td></td></tr><tr><td>Simple 2D</td><td>BIFS pour objets audiovisuels mais n'offrant pas d'intéractivité. (Télévision numérique)</td><td></td></tr></tbody></table>

Suite page suivante
<table><caption>TAB. 1.3 – Définition des profiles et niveaux Mpeg-4</caption><thead><tr><td>Type de Profils</td><td>Profils</td><td>Types d'objets concernés</td><td>Exemples d'applications visés</td></tr></thead><tbody><tr><td></td><td>Complete 2D</td><td>BIFS pour toute application 2D avec possibilité de transformations, alpha blending et d'intéractivité</td><td></td></tr><tr><td></td><td>Complete</td><td>BIFS pour les applications complexes comme les jeux et les mondes virtuels dynamiques en 3D</td><td></td></tr><tr><td>Object Description Profile</td><td></td><td>Un seul Profile mais plusieurs Levels afin de décrire les différents OD, SL, OCI et IPMP</td><td></td></tr></tbody></table>

### 1.3.3 Notion de scène - BIFS (Binary Format for Scene description)

Une introduction à la notion de BIFS a été réalisée dans [SFE00]. Mpeg-4 est un standard basé sur la description d'objets, c'est-à-dire que les programmes radio, les films télévisés et autres applications basées sur la technologie Mpeg-4, manipulent des objets multimédias. Ces objets peuvent être par exemple des segments de films vidéo, des images fixes, des enregistrements audio, des images de synthèse, des sons de synthèse (Fig 1.12). La méthode de codage de chaque type est spécifiée dans le standard Mpeg-4, ce qui permet un codage optimisé.

Plusieurs objets peuvent être combinés pour former une scène, comme cela est montré sur la figure 1.11, mais un objet seul peut également constituer une scène. Les objets sont des éléments indivisibles dans une scène. Dans cette figure, la scène est constituée des objets suivants: le fond (2 objets: un globe et un bureau), une personne (2 objets: la séquence vidéo du corps et la séquence audio de sa voix) et le tableau sur lequel un document audiovisuel défile (1 objet: présentation powerpoint par exemple). Dans cet exemple, on notera la hiérarchisation de la scène. Les actions de l'utilisateur peuvent se faire à plusieurs niveaux de la hiérarchie, comme par exemple, supprimer le personnage (et donc les objets qui le définissent), augmenter le volume de la voix. Ceci peut apporter une qualité accrue sur les objets ou ensembles d'objets importants à un instant donné.

Le système récepteur (TV, PC ou autre) récupère la description de ces objets, leur action et position dans la scène, ainsi que les relations entre eux pour reconstituer la scène. Les instructions nécessaires pour construire la scène à partir d'objets sont les BIFS. (Binary Format for Scene Description). L'utilisateur a également la possibilité d'agir sur la représentation de la scène de manière interactive (Figure 1.12). La manipulation des objets de cette scène par l'utilisateur se fait également par les BIFS.

Ces BIFS sont élaborés pour une transmission concise des scènes et de leurs manipulations.
<figure><img src="image_16.png" /><figcaption>FIG. 1.11 – Objets audiovisuels organisés en scène.</figcaption></figure>
lations. [SVH99] décrit les BIFS utilisés pour le contrôle des objets audio (reconstitution sonore en fonction du matériel utilisé, des interactions avec l'utilisateur, effets 3D et/ou chargement dynamique d'effets spécifiques). La plupart des concepts manipulés par les BIFS proviennent du langage VRML (Virtual Reality Modeling Language).

L'utilisateur peut :

- déplacer les objets dans une scène,

- faire varier les caractéristiques géométriques et acoustiques des objets,

- regrouper les objets entre eux pour former de nouvelles scènes,

- envoyer des informations aux objets afin qu'ils modifient leurs attributs (animation de visages de synthèse, texture variable d'un objet, sons),

- se déplacer dans la scène.

<figure><img src="image_17.png" /><figcaption>FIG. 1.12 – *Manipulation d'une scène.*</figcaption></figure>

### 1.3.4 Codage des objets

#### 1.3.4.1 Objets audio

La partie audio de Mpeg-4 fournit des outils pour la manipulation de sons naturels, comme la parole ou la musique, mais également celle de sons de synthèse. La représentation de sons de synthèse peut être issue d'un texte (synthèse vocale) ou d'instruments virtuels, avec ou sans ajout de paramètres permettant de créer des effets comme la réverbération, la
spatialisation. Cette représentation permet non seulement une compression efficace mais également la scalabilité et le traitement d'effets.

La partie audio de Mpeg-4 couvre des débits allant de 6 à 24 Kbits/s et a déjà été testée dans des applications d'émissions radios AM numériques. Il en résulte une qualité supérieure aux émissions AM classiques, pour une même largeur de bande.

Pour le codage de la parole, deux techniques sont utilisées: HVXC (Harmonic Vector eXitation Coding) pour des débits compris entre 2 et 4 Kbits/s, et CELP (Code Excited Linear Predictive) pour des débits supérieurs et jusqu'à 24 Kbits/s. Pour des documents audio quelconques, on utilise les codages TwinVQ ou AAC, avec des fréquences d'échantillonnage à partir de 8 kHz.

Un flux d'information peut être décodé par plusieurs décodeurs de complexité variable, suivant la qualité désirée pour l'application. Le système Mpeg-4 est capable de décoder les flux audio Mpeg-2.

En ce qui concerne les sons de synthèse, Mpeg-4 définit des décodeurs de sons générés à partir d'un ensemble de données "structurées". Par exemple, les textes sont convertis en sons grâce au TTS décodeur (text-to-speech), et les sons plus généraux, dont la musique, sont générés à partir de sons de base. Ceci permet des débits très faibles pour un son de bonne qualité.

Text-To-Speech (TTS) est un codeur fournissant des débits entre 0.2 et 1.2 Kbits/s et permet de générer un signal de parole synthétisé intelligible, à partir d'un texte et, éventuellement, de paramètres prosodiques (pitch, durée des phonèmes). Le flux codé comporte les informations permettant de synchroniser la parole sur une animation de visage. Ce n'est pas le TTS synthétiseur qui est défini dans la norme, mais son interface (TTSI- Text To Speech Interface).

Structured Audio Orchestra Language (SAOL) est un langage standard Mpeg-4 permettant de contrôler le décodeur audio. Il permet de créer et contrôler un orchestre constitué d'instruments définis dans le flux d'information. Un instrument est constitué d'un réseau de signaux de base qui peuvent être combinés pour créer des sons comme c'est le cas d'un instrument "classique". Il n'existe pas une méthode de synthèse unique, il est possible de créer ses propres méthodes (instruments, effets). Le contrôle de la synthèse est réalisé par le chargement de "scores" ou "scripts" (textes) dans le flux. Les "scores" sont des jeux de commandes permettant de mettre en œuvre les différents instruments aux bons instants afin de générer un signal audio dans son ensemble. Le langage SASL (Structured Audio Score Language) permet de décrire ces scores, mais également de créer de nouvelles commandes et de nouveaux sons. Pour des applications plus simples, le protocole MIDI peut être utilisé pour contrôler l'orchestre.

Pour les terminaux ne possédant que peu de fonctionnalités, ou pour les applications basiques, il existe un format pour les sons standard. Les échantillons de sons ainsi que les effets (filtres, réverbération, choeurs) sont chargés sous ce format. La simple lecture du flux d'information permet de former le signal sonore, ce qui est impossible avec SAOL.

### 1.3.4.2 Objets vidéo

Comme pour les documents sonores, les objets visuels peuvent être d'origine naturelle ou de synthèse. Mpeg-4 fournit des outils performants pour manipuler des objets de synthèse standard comme l'animation de visage, de corps et des maillages animés en 2D.
Le codage de forme arbitraire peut être réalisé de nombreuses manières, toutes basées sur un même schéma global (Fig 1.13). Les différences portent sur la méthode utilisée pour coder les formes quelconques des objets, la méthode pour coder la texture, le mode pour estimer et coder le mouvement des objets, et la façon d'incorporer les informations dans le flux de bits.

<figure><img src="image_18.png" /><figcaption>FIG. 1.13 – Schéma global de codage d'objets vidéo de forme quelconque.</figcaption></figure>

Mpeg-4 fournit les schémas relatifs aux décodeurs de texture, de forme et de mouvement [EH00]. Les algorithmes de codage de texture sont extrêmement performants, combinant les techniques de codage comme l'estimation et la compensation de mouvement, la DCT, balayage zig-zag, la quantification et le codage VLC (Fig 1.13). Les codages par ondelettes peuvent être également utilisés. Ensuite, le codage de la forme doit permettre de décrire des objets de toutes formes en ajoutant aux composantes de la luminance et des chrominances, une composante binaire ou de niveaux de transparence. Cette composante binaire est non nulle pour un pixel compris dans l'objet, et nulle sinon. Si le découpage de la forme doit être plus précis, et l'intégration de l'objet dans la scène moins visible, on peut utiliser un codage de la composante sur 256 niveaux de transparence. L'utilisation du codage de forme, bien que très instinctif, est extrêmement complexe à mettre en œuvre, les algorithmes de détection et de suivi de contours, qui ne font pas l'objet de descriptions dans le standard, sont extrêmement lourds en calculs et nécessitent souvent l'intervention de l'utilisateur pour corriger les erreurs commises. Le décodeur de mouvement récupère les vecteurs de mouvement dans le flux codé pour effectuer une translation et retrouver l'image d'origine.
<figure><img src="image_19.png" /><figcaption>FIG. 1.14 – Exemple de coefficients caractéristiques du visage.</figcaption></figure>

### 1.3.4.3 Animations de corps humains

C'est une des spécificités du standard. Un visage ou un corps est un objet codé différemment des autres objets vidéo [AMT00]. Le concept est de représenter un visage ou un corps à l'aide d'un ensemble de noeuds (Fig. 1.14) décrivant les points caractéristiques d'une structure modèle, et d'animer ces noeuds pour créer la séquence vidéo du visage ou du corps. Le flux d'information contient deux types de paramètres : les FDP (Facial Definition Parameter), qui permettent de définir les caractéristiques telles que la forme, l'expression et la texture, et les FAP (Facial Animation Parameter) qui concernent les mouvements de l'objet.

Initialement, un visage standard modèle peut être construit. La réception du flux contenant les FAP va permettre de simuler la parole et les mouvements du visage. La réception des FDP va permettre de transformer le visage standard en un visage spécifique, réel ou non.

Une application directe est celle de la visiophonie car cela permet de transmettre en temps réel des animations de visages d'une bonne qualité et à faible débit. L'animation de corps peut être mise à profit également dans le domaine des jeux interactifs par exemple.

### 1.3.4.4 Objets maillés ("mesh objects")

Il s'agit d'un modèle 2D qui permet de représenter des images 3D par projection de triangles 3D constituant l'objet sur une image plane. Un maillage [AMT00] correspond à un ensemble de points ("nodes") sur l'image définissant des triangles plans. On associe à chaque triangle une texture. Un exemple de maillage est donné figure 1.15.

Par déformation du maillage, on peut animer l'objet de manière efficace et créer une séquence vidéo. Il est possible de superposer un objet quelconque sur des maillages
<figure><img src="image_20.png" /><figcaption>FIG. 1.15 – Exemple de maillage 2D.</figcaption></figure>

spécifiques. Par exemple, si on applique un drapeau quelconque, rectangulaire, sur un maillage avec mouvement d'ondulation, on observe un drapeau semblant flotter au vent.

Le maillage peut également être adapté au codage d'un objet, on parle de "content-based mesh". Le codage de la séquence vidéo de l'objet consiste à construire son maillage et à échantillonner les vecteurs de mouvement de quelques points caractéristiques sur le contour et à l'intérieur de l'objet. La sélection des points n'est pas spécifiée dans le standard.

### 1.3.5 DMIF: Delivery Multimedia Integration Framework

C'est le protocole utilisé pour gérer les flux d'information entre le PC utilisateur et la source d'information éloignée, quelle que soit la technologie employée. Le principe utilisé est comparable à celui de FTP ("*File Transfer Protocol*"), à la différence près que FTP renvoit des données alors que DMIF renvoit des pointeurs sur une source d'information.

La première opération en FTP, c'est l'ouverture de la session avec l'autre ordinateur éloigné. Ensuite, les fichiers sont sélectionnés et FTP demande le chargement des fichiers. Les fichiers sont envoyés sur une connexion séparée. De la même manière, après ouverture de la session, DMIF demande l'ouverture de connexions. La réponse est fournie sous forme de pointeurs sur des flux où pourront transiter les informations. Les fonctionnalités offertes par DMIF sont accessibles grâce à une interface appelée la DAI (DMIF Application Interface). Les messages envoyés par le DMIF diffèrent selon le réseau utilisé, ce qui est transparent au niveau utilisateur grâce au DAI.

La qualité de service est gérée par le DMIF, la DAI permettant à l'utilisateur de spécifier ses recommandations sur les flux désirés.

La figure 1.16 présente le concept utilisé. Une application requiert l'accès à des informations. Qu'elles proviennent de systèmes "broadcast", qu'elles soient stockées de manière locale ou sur un système éloigné, l'application établit une communication uniquement à
<figure><img src="image_21.png" /><figcaption>FIG. 1.16 – *Architecture DMIF*.</figcaption></figure>

l'aide de la DAI.

### 1.3.6 Protection et gestion de la propriété intellectuelle - IPMP

La protection des informations est un problème de la plus haute importance pour développer des applications comme le télé-achat, ou pour éviter les copies illicites de documents ayant des droits d'auteur. Pour cette protection, les documents audio, par exemple, peuvent contenir des données cachées dans le flux de bits, permettant de savoir si la copie est légale ou non. Si elle ne l'est pas, on doit pouvoir identifier l'origine de la copie et ainsi remonter à la source de la fraude. Mpeg-1 n'offrait aucune possibilité a ce niveau, Mpeg-2 a apporté une solution simple permettant le "pay per view".

Mpeg-4 fournit le système IPMP (Intellectual Property Management and Protection), qui est une interface normalisée permettant de gérer les droits. Cette interface permet de définir les flux de bits élémentaires (ES pour Elementary Streams) et descripteurs (OD pour Object Descriptor) spécifiques à l'IPMP. Les descripteurs IPMP sont mêlés aux flux des OD associés aux autres objets de la scène, alors que les ES IPMP contiennent des informations évoluant dans le temps et qui sont associées à de multiples OD. Mpeg-4 ne fournit aucune description en ce qui concerne les techniques de protection à utiliser, mais ces techniques accèdent aux données contenues dans le flux de bits grâce à l'interface standard. Le système IPMP contrôle un grand nombre de points clefs du schéma de codage global pour plus de sécurité (Fig. 1.17). Un document peut ne comporter aucun élément IPMP : il n'est alors pas protégé.

Cette partie est spécifiée dans la partie système de la norme.

### 1.3.7 Protocole de transmission : partie système

L'ensemble des informations sur le protocole de transmission des objets codé est décrit dans la partie système de Mpeg-4. Cette partie complexe de la norme fournit la description
<figure><img src="image_22.png" /><figcaption>FIG. 1.17 - Les points de contrôle IPMP dans le schéma global de codage</figcaption></figure>

des accessoires de la figure 1.18 :

- un modèle de temps et de buffers permettant au terminal émetteur de prédire la manière dont le récepteur réagira en termes de gestion des buffers, ainsi qu'en termes de synchronisation lors de la reconstruction des informations,

- la description des BIFS,

- la description de l'interface IPMP,

- la description du "compression layer". Chaque objet est codé de manière indépendante et possède un ou plusieurs Object Descriptor (OD) qui contient la position des données codées dans le flux de bits, les informations permettant de situer cet objet dans la scène, les interactions avec les autres éléments de la scène, IPMP. Les données codées des objets, ainsi que les OD, constituent des flux de bits élémentaires appelés ES (elementary streams). La gestion de ces éléments est gérée dans le "compression layer",

- la description des SL (Sync Layers) permettant de gérer la synchronisation des ES. Le flux de bits contenant les ES et les informations de synchronisation sont les SL-packetized streams,

- la description des Flexmux qui permettent le Multiplexage des différents SL-packetized streams en un unique flux de bits à transmettre,

- la description de la DAI.

On peut remarquer qu'après la phase de codage proprement dite, qui permet de réduire la taille de données à transmettre, on ajoute alors un certain nombre d'informations qui alourdissent les échanges. Cette partie système va permettre de mettre en œuvre divers objets codés séparément dans une scène unique, de rendre les échanges avec les différents
périphériques de communication transparents pour l'application, de gérer les interactions avec l'utilisateur. Mpeg-4 perdra ainsi un peu d'efficacité en termes de codage pur pour assurer par contre de précieux services au développement de nouvelles applications.

<figure><img src="image_23.png" /><figcaption>FIG. 1.18 – *Architecture du terminal.*</figcaption></figure>

## 1.4 Besoins pour Mpeg-4

La norme Mpeg-4 regroupe un ensemble très divers d'outils pour le codage et le transport d'informations audiovisuelles. Les solutions de codage à utiliser n'intègrent pas le standard, et font l'objet de nombreuses études. Par exemple, des techniques de codage de formes, d'extraction de maillages de points caractéristiques d'un visage, fonctionnent
soit dans des cas particuliers (extraction de la forme d'un objet ou d'une personne lorsque l'arrière plan est de couleur bleue ou verte), soit ne sont pas encore totalement automatiques et suffisamment rapides. Les axes de recherche en **analyse des images** doivent être fortement mis à contribution dans les applications complexes visées par Mpeg-4.

Les solutions mises en œuvre pour l'implantation des algorithmes Mpeg-2 doivent être de nouveau étudiées car elles ne sont plus forcément valides. En effet, Mpeg-4 ne donne pas lieu à une application, comme le faisait Mpeg-2, mais couvre un ensemble d'applications qui ne nécessite pas la totalité des algorithmes. D'autre part, les possibilités offertes sont très larges, mais ne sont réalisables qu'avec une très forte puissance de calcul. Malgré les progrès réalisés sur les unités de calcul, l'intégration de nombreux outils du standard reste problématique.

Pour que le standard Mpeg-4 puisse s'imposer comme a pu le faire Mpeg-2, des solutions de codage temps réel doivent pouvoir être proposées. Dans un premier temps, les décodeurs et outils de visualisation, plus simples à développer, sont proposés. Mais les solutions de codage, et donc la production de contenu Mpeg-4, restent complexes. Si les outils les plus "classiques" comme le codage de vidéo rectangulaire naturelle commencent à trouver des solutions automatiques et assez rapides, les défis restent nombreux pour qu'il en soit de même pour la totalité des outils Mpeg-4.
# Chapitre 2

## Analyse des architectures matérielles

Actuellement, on assiste à un formidable développement de circuits basés sur des technologies sans cesse en évolution et atteignant des performances qui s'accroissent exponentiellement : systèmes mono ou multi-puces, processeurs standard ou de traitement du signal, circuits logiques programmables ou circuits dédiés, architectures homogènes ou hétérogènes... Chaque circuit possède des spécificités qui le rendent plus ou moins apte à traiter une classe d'applications donnée.

Aussi, afin de mieux appréhender notre plate-forme cible et les choix réalisés, ce chapitre résume les principales caractéristiques matérielles et logicielles des systèmes les plus fréquemment rencontrés. Les avantages et les inconvénients les solutions multi-composants seront ensuite exposés. Le paragraphe suivant précisera les spécificités du traitement des images. Enfin, quelques méthodologies de conception seront détaillées.

### 2.1 Présentation des unités de calcul

Cette section s'articule autour des principales caractéristiques des circuits. Elle synthétise les informations d'une part sur les processeurs standard, et d'autre part sur les processeurs dédiés au traitement du signal.

#### 2.1.1 Processeurs standard

De part leur haute flexibilité et leurs fréquences d'horloge toujours à la pointe, ces composants sont habituellement utilisés pour les cartes mères de PC. Des versions comme celles des ordinateurs portables sont développées pour l'embarqué. Leur consommation est alors contrôlée en ajustant dynamiquement la fréquence et la tension d'alimentation en fonction des besoins de l'application. Ils sont également pourvus d'un mode "sommeil" obtenu en réduisant la tension au repos. Ces gains en consommation permettent de plus de ne pas coupler le processeur à un ventilateur généralement bruyant, encombrant et consommateur d'énergie.

Les processeurs standard sont particulièrement adaptés aux applications multimédia grâce à l'utilisation de jeux d'instructions spécifiques, comme c'est le cas pour les Pentium
depuis l'introduction des instructions MMX en 1997. La nouvelle génération de cartes de traitement d'images intègre d'ailleurs des processeurs standard, en particulier le PowerPC G4 de Motorola et les Pentium d'Intel. L'utilisation optimale de ces instructions nécessite des connaissances pointues et spécifiques, mais aboutis à utiliser le parallélisme inhérent des calculs multimédia.

L'augmentation des performances des processeurs (Fig. 2.1) a permis l'implantation logicielle d'applications autrefois réservées aux circuits spécifiques, avec l'avantage de l'universalité. Celle des décodeurs Mpeg-2 est notamment réalisable. Citons par exemple l'encodeur et le décodeur logiciels de la société Ravisent capables de coder ou de décoder en temps réel de la vidéo au format CIF avec un pentium II à 400 MHz [Cra99]. L'encodeur logiciel de la société Ligos réalise le codage temps réel d'images CIF sur un pentium II à 300 MHz, et son décodeur "main@Main" fonctionne en temps réel sur pentium II à 450 MHz.

<figure><img src="image_24.png" /><figcaption>FIG. 2.1 – *Performances des processeurs*</figcaption></figure>

Les performances annoncées par Intel pour ses processeurs vers 2010 sont une puissance de cent mille MIPS (Million of Instruction Per Second) comme l'illustre la figure 2.1. Pour cela, Intel compte sur sa future technologie "Hyper-Threading" [Gro01] basée sur un fort parallélisme de calcul. Le système d'exploitation verra un processeur physique, mais, en réalité, ce seront deux processeurs logiques qui se répartiront automatiquement les calculs. Dans un processeur basique, les instructions sont mises en file d'attente et traitées les unes après les autres dans un ordre logique. C'est la définition de cet ordre qui donne l'impression de parallélisme entre plusieurs applications. Le succès de cette technologie "Hyper-Threading" repose sur le développement de systèmes d'exploitation et de logiciels applicatifs adaptés à ces systèmes d'exploitation. Intel annonce ces nouveautés pour l'année 2003.

Cependant, les processeurs standard restent des produits onéreux et inadaptés aux fortes contraintes d'embarquabilité, c'est pourquoi l'utilisation de processeurs de traitement du signal (DSP) leur est souvent préférée.
## 2.1.2 Processeurs de traitement du signal : DSP

### 2.1.2.1 Présentation générale

Les premiers processeurs de traitement du signal (DSP : Digital Signal Processor) ont été produits en 1982 par Texas Instruments afin de répondre aux besoins des applications de traitement du signal comme le traitement des images, mais également la reconnaissance et la synthèse vocale, les télécommunications, le contrôle temps réel. Actuellement, les DSP sont devenus incontournables et se retrouvent dans les lecteurs de disques compacts, les téléphones portables, ou encore les capteurs automobiles.

Dans les téléphones portables par exemple [SDB01], le DSP n'occupe que 20% du logiciel embarqué, mais requiert 80% de la puissance en MIPS pour :

- le codage de la parole,

- le cryptage,

- le modem,

- l'élimination d'écho,

- le décodeur MP3,

- la reconnaissance de la parole.

Les DSP devront à l'avenir prendre en charge également les algorithmes de synthèse de la parole et de décompression des images Mpeg-4 dans sa troisième génération prévue en 2003. Pour y parvenir, ils sont déjà dotés d'un certain nombre de spécificités que nous détaillons ci-dessous.

### 2.1.2.2 Virgules fixe et flottante.

Deux familles de DSP sont proposées : les processeurs à virgule fixe et les processeurs à virgule flottante.

<figure><img src="image_25.png" /><figcaption>FIG. 2.2 – Données codées en virgule fixe</figcaption></figure>

En virgule fixe (Fig. 2.2), par une représentation des nombres fractionnaires, les bits sont lus comme des fractions de puissance négatives de 2. Ainsi, le nombre 0,75 s'écrit 0.5+0,25, soit 6000 en hexadécimal, ou encore (0110-0000-0000-0000) au format 16
bits. La principale limitation de ce format est la plage de variation comprise entre -1,0 et +1,0 qui oblige le programmeur à bien définir son codage. Par contre, l'architecture de calcul, notamment la multiplication de deux nombres est relativement simple.

**En virgule flottante**, les données sont codées sous la forme d'une mantisse, multipliée par un exposant. L'illustration de ce codage est représentée figure 2.3. La plage de variation des nombres est alors limitée de $5,8 \times 10^{-39}$ à $3,4 \times 10^{38}$ (sur un processeur 32 bits).

<figure><img src="image_26.png" /><figcaption>FIG. 2.3 – Données codées en virgule flottante</figcaption></figure>

Les processeurs à virgule fixe possèdent une architecture simple, ce qui implique un faible coût et de faibles consommations. C'est ce qu'utilise la téléphonie mobile. Les processeurs à virgule flottante sont plus complexes. Leur coût plus élevé et leur forte consommation sont néanmoins compensés par une plus grande puissance de calcul, par la possibilité de traiter des signaux de très grande dynamique, et par la simplicité de la programmation : le programmeur n'a en effet pas à se soucier des problèmes de précision et d'arrondis inhérents à la virgule fixe.

### 2.1.2.3 Architecture mémoire.

La plupart des architectures de DSP sont de type Harvard, c'est-à-dire basées sur le concept d'un processeur connecté à deux bancs mémoire indépendants (mémoire programme et mémoire de données) via deux bus indépendants (Fig. 2.4). Ainsi, l'accès aux mémoires programme et données peut être effectué simultanément. De plus, il est parfois possible d'obtenir plusieurs accès mémoire pendant un seul cycle d'horloge, rendant très rapides les transferts de données dans le DSP. Certaines architectures sont dites Harvard modifiées, comprenant dans ce cas trois bancs mémoires, chacun rattaché à son propre bus, la mémoire supplémentaire pouvant accueillir du programme ou des données.

Ces mémoires sont caractérisées par la taille de leurs bus. Généralement comprise entre 16 et 32 bits, la taille des données influe sur le coût du composant et sa surface : l'utilisation de larges bus signifie plus de liaisons internes et externes au processeur, mais aussi l'utilisation de mémoires externes plus importantes. L'avantage est d'obtenir une précision plus importante sur les calculs ou d'obtenir des transferts de données plus rapides pour une précision égale. Enfin, les DSP ont une architecture mémoire à accès multiple, ceci pendant un cycle d'instruction. Plusieurs modes d'adressages spécialisés sont disponibles. Le concepteur doit donc choisir la taille de données la plus réduite possible que son application puisse supporter.
<figure><img src="image_27.png" /><figcaption>FIG. 2.4 – Architectures classique et Harvard</figcaption></figure>

### 2.1.2.4 Opérateurs spécifiques.

Les architectures des DSP intègrent des opérateurs dédiés spécialisés (multiplieurs, ALU, registres, etc.) qui améliorent les calculs spécifiques régulièrement rencontrés.

La plupart intègrent une structure MAC (multiplieur-accumulateur) intégrée dans le chemin de donnée. Cette structure permet d'effectuer une multiplication et une accumulation en un seul cycle d'instruction et s'avère donc très utile pour les algorithmes intégrant un produit de vecteurs (filtrage numérique, corrélation ou transformée de Fourier).

### 2.1.2.5 Périphériques.

Un autre atout des DSP est de posséder de nombreux périphériques spécialisés ainsi que des interfaces d'entrées/sorties parallèle ou série très intéressantes pour le temps réel et les systèmes embarqués. On rencontre souvent un ou plusieurs DMA permettant la gestion des transferts de données sans l'intervention du CPU. Les DSP possèdent fréquemment des timers permettant la gestion ( périodique ou apériodique) des entrées/sorties. On trouve également des convertisseurs (CAN et CNA) permettant d'établir des liens de conversion entre les éventuelles données analogiques et numériques. Il peut aussi y avoir des entrées/sorties vidéo ou audio. Les fournisseurs proposent dans une même famille de DSP plusieurs versions contenant des périphériques différents afin d'adapter leur offre à des applications précises.

### 2.1.2.6 Nouvelles architectures.

Depuis leur création, les DSP ont considérablement évolué pour répondre aux besoins croissants en termes de puissance de calcul. Les améliorations, comme pour les processeurs standards, se trouvent dans l'utilisation de nouvelles technologies qui ont permis d'élever les fréquences horloge, de diminuer les consommations, d'accélérer les transferts de données ou encore d'augmenter la taille des mémoires internes. Les fournisseurs proposent des évolutions architecturales permettant de réaliser toujours plus de calculs par cycle, et donc de diminuer les temps de calculs tout en limitant la montée en fréquence, synonyme de consommation élevée.
Traditionnellement, les DSP utilisaient un jeu d'instructions complexe qui permettait
au programmeur de réaliser plusieurs calculs avec une seule instruction. Par exemple,
certains DSP autorisaient la spécification de toutes les opérations et des transferts de
données nécessaires au calcul de plusieurs étapes de l'algorithme d'un filtre FIR en une
seule instruction. D'autre part, les DSP traitaient une unique instruction par cycle horloge.
Cette approche permettait aux DSP d'obtenir de bonnes performances tout en minimisant
la taille du programme.

Afin d'accroître le nombre de données manipulées pour chaque instruction, tout en
conservant l'architecture traditionnelle d'un DSP, il est envisageable d'augmenter la lar-
geur des données avec des informations d'exécution supplémentaires. Ainsi, alors qu'une
instruction ne peut classiquement utiliser qu'un multiplieur, elle peut grâce à cette tech-
nique en manipuler plusieurs. L'architecture de base du DSP est conservée, mais les unités
de calcul plus nombreuses. La taille du jeu d'instructions se trouve agrandie et le pro-
grammeur doit bien connaître le composant pour tirer parti de cette architecture. Un bon
exemple de cette approche est le DSP16000 de Lucent Technologies basé sur le DSP1600,
incorporant un second multiplieur, un additionneur indépendant et une unité de manipu-
lation de bits. La taille du bus de données est alors passée de 16 à 32 bits pour pouvoir
réaliser plusieurs opérations en parallèle. La taille du programme reste faible par rapport
aux calculs effectués. Actuellement, peu de DSP peuvent, comme le DSP16000, réaliser
deux opérations MAC par cycle d'horloge.

Une autre stratégie est de s'éloigner complètement des architectures standard des DSP pour utiliser plusieurs instructions par cycle d'horloge. On peut citer à cet effet les architectures VLIW (Very Long Instruction Word) développées pour les TMS320C62xx Texas Instruments (Part. 3.1.2.1) ou TriMedia Philips. Chaque instruction peut alors être divisée en plusieurs instructions élémentaires qui sont exécutées en parallèle sur des unités de calcul différentes. Le jeu des instructions élémentaires reste relativement simple, le parallélisme maximum est en revanche difficile à obtenir à cause des dépendances de données et de la taille limitée des transferts de données. Les instructions VLIW sont alors utilisées et mènent à des programmes relativement longs. Le VLIW doit également utiliser plusieurs bus internes conséquents qui mènent à une forte consommation. En revanche, la puissance maximale de calcul des VLIW est très importante en comparaison des DSP plus classiques.

Comme les VLIW, les architectures superscalaires permettent d'exécuter plusieurs instructions en parallèle. Alors que pour un VLIW, les instructions parallèles sont déterminées au moment de la compilation (soit par le programmeur, soit par le compilateur), les DSP superscalaires gèrent l'ordonnancement des instructions de manière dynamique et déterminent en fonction des données et calculs a réaliser celles qui peuvent être parallélisées. Cette technique utilisée pour les processeurs standard Pentium et PowerPC, est utilisée par le ZSP164XX de ZSP Corporation.

Quant à Oxford Micro Devices, ils développent un DSP sur une base de processeur RISC (Reduced Instruction Set Computer) ordinaire, c'est-à-dire avec un jeu d'instructions limité mais permettant une exécution rapide de chacune d'elles, avec la particularité suivante : les instructions parviennent à contrôler à la fois une unité arithmétique et logique scalaire, et des unités arithmétiques parallèles. Plusieurs opérations identiques réalisées sur des données différentes sont calculées simultanément sur un opérateur parallèle. Ceci correspond au principe SIMD (Single Instruction Multiple Data) que l'on retrouve dans les
instructions MMX pour Pentium, AltiVec pour PowerPC, ainsi que pour les DSP SHARC Analog Devices et DSP16000 déjà cités.

Le DSP StarCore développé conjointement par Motorola et Lucent propose encore une architecture parallèle, mais différente : il possède 4 cœurs de DSP synchronisés travaillant en parallèle, afin d'obtenir la puissance de 1200 MIPS.

### 2.1.2.7 Programmation.

L'écriture d'un programme en assembleur demeure la solution qui profite au mieux des spécificités architecturales d'un DSP. Il est toutefois plus facile d'écrire un programme en C, ce langage étant supporté par la totalité des DSP à travers compilateurs et débogueurs (Fig. 2.5). Cependant, ces compilateurs C ne s'avèrent pas tous égaux en termes d'efficacité pour générer un code exécutable optimal.

En revanche, la façon d'écrire le programme en C a une influence significative sur l'efficacité du code généré. Il existe donc une phase d'adaptation du code C à ce que nous pouvons appeler un "code C pour DSP", permettant au compilateur de tirer le meilleur parti de l'architecture de calcul (Fig. 2.5).

<figure><img src="image_28.png" /><figcaption>FIG. 2.5 – Programmation d'un DSP</figcaption></figure>

Par ailleurs, l'utilisation de bibliothèques spécifiques (Fig. 2.5) apporte des résultats optimaux pour des calculs particuliers comme la FFT, ou des implantations automatiques de protocole. Aussi, les bibliothèques fournies peuvent être un critère décisif dans le choix d'un DSP.

### 2.1.2.8 Choix d'un DSP.

Le choix d'un DSP reste complexe puisqu'il s'effectue en fonction de l'ensemble des caractéristiques que nous venons de citer et en fonction de l'application visée. Le tableau 2.1 répertorie les principaux fournisseurs de DSP.

On observe ainsi que deux DSP différents, cadencés à la même fréquence, ne fournissent pas obligatoirement la même puissance de calcul : le choix n'est donc pas simple. De plus, la valeur de la puissance de calcul donnée en MIPS ne fournit qu'une estimation relative. En
<table><caption>TAB. 2.1 – Principaux fournisseurs de DSP</caption><thead><tr><th>Rang mondial</th><th>Vendeur</th><th>Familles de DSP</th><th>Virgule</th><th>Données (bits)</th><th>Puissance (MIPS)</th></tr></thead><tbody><tr><td rowspan="6">1</td><td rowspan="6">Texas Inst.</td><td>TMS320C1x</td><td>Fixe</td><td>16</td><td>8.8</td></tr><tr><td>TMS320C2x</td><td>Fixe</td><td>16</td><td>40</td></tr><tr><td>TMS320C3x</td><td>Flottante</td><td>32</td><td>25</td></tr><tr><td>TMS320C4x</td><td>Flottante</td><td>32</td><td>30</td></tr><tr><td>TMS320C5x</td><td>Fixe</td><td>16</td><td>50</td></tr><tr><td>TMS320C6x</td><td>Fixe</td><td>32</td><td>2400</td></tr><tr><td rowspan="2">2</td><td rowspan="2">Analog Devices</td><td>ADSP-21xx</td><td>Fixe</td><td>16</td><td>40</td></tr><tr><td>ADSP-21</td><td>Flottante</td><td>32</td><td>40</td></tr><tr><td rowspan="6">3</td><td rowspan="6">Motorola</td><td>DSP560xx</td><td>Fixe</td><td>24</td><td>40</td></tr><tr><td>DSP563xx</td><td>Fixe</td><td>24</td><td>80</td></tr><tr><td>DSP568xx</td><td>Fixe</td><td>16</td><td>70</td></tr><tr><td>DSP960xx</td><td>Flottante</td><td>32</td><td>40</td></tr><tr><td>StarCore</td><td>Fixe</td><td>16</td><td>1200</td></tr><tr><td>DSP16xx</td><td>Fixe</td><td>16</td><td>40</td></tr><tr><td>4</td><td>Lucent</td><td>DSP32xx</td><td>Flottante</td><td>32</td><td>40</td></tr></tbody></table>

effet, pour une architecture VLIW, la valeur en MIPS est donnée lorsque le parallélisme maximum est atteint, situation rarement rencontrée en pratique. La comparaison peut s'effectuer sur le temps d'une opération donnée sur des "benchmark": le temps de calcul d'une FFT par exemple est régulièrement utilisé. La figure 2.6 illustre ce fait pour des calculs de FFT 256 points, résultats qui doivent être rapportés à la fréquence de l'horloge du processeur. On notera que les Pentium III-C et TMS320C6701 sont à virgules flottantes alors que les autres sont à virgules fixes. Les performances des DSP apparaissent alors de premier ordre puisqu'ils sont parmi les plus rapides pour des fréquences horloge faibles, symonymes de faible consommation. Les autres DSP (DSP56311 et TMS320C5410), avec des fréquences horloge similaires, sont six à sept fois plus lents. Les Pentium sont rapides, mais avec des fréquences horloge cinq fois plus importantes, et donc avec une consommation conséquente.

Des analyses détaillées sont disponibles par exemple auprès de BDTI [BDT01] ou du consortium EEMBC.

<figure><img src="image_29.png" /></figure>

<figure><img src="image_30.png" /><figcaption>FIG. 2.6 – Comparaison de quelques processeurs.</figcaption></figure>
Malgré leur complexité croissante, la tendance reste à des DSP totalement programmables en C standard. Ces processeurs présentent ainsi une relative facilité de reprogrammation, associée à de petites tailles de composants. En revanche, l'utilisation du compilateur nécessite une certaine expérience, car les performances sont directement liées à sa bonne utilisation. De nombreuses options doivent être choisies pour optimiser les performances du compilateur et pour que le DSP utilise au maximum le parallélisme potentiel de son architecture interne.

Pour chaque constructeur, l'effort pour les années à venir concerne une montée en puissance, bénéficiant à la fois des progrès dans la miniaturisation, dans la rapidité des circuits intégrés mais aussi dans la généralisation des architectures parallèles.

### 2.1.3 Circuits spécialisés

Les circuits spécialisés, comme leur nom l'indique, sont parfaitement adaptés à une application et sont performants tant en termes de rapidité que de consommation. Nous allons présenter ici les FPGA puis les circuits dédiés ASIC.

#### 2.1.3.1 Circuits programmables de type FPGA

Le FPGA, Field Programmable Gate Array, ou réseau de portes programmable sur site, a fait son apparition dans le milieu des années 1980 (les tous premiers furent créés en 1984 par Xilinx), ouvrant une nouvelle voie dans la conception des systèmes de vision temps réel. Il était destiné à l'origine au remplacement des circuits logiques classiques en vue d'une plus grande intégration.

Les FPGA font partie de la famille des circuits programmables ou PLD ("Programmable Logic Device"). Deux technologies sont disponibles : les FPGA de type RAM (dans la famille des Xilinx, des Virtex et Spartan) et ceux à anti-fusible. Les FPGA à anti-fusible sont programmables une seule fois, mais grâce à une technologie plus simple, offrent une consommation faible. En revanche, les FPGA de type RAM peuvent être reprogrammés indéfiniment par l'utilisateur et ainsi évoluer dans le temps. Bien que plus lents et moins denses, ces derniers sont plus utilisés car ils permettent un prototypage rapide, sont faciles à mettre au point et sont reconfigurables de manière dynamique.

Les FPGA sont constitués d'un réseau de blocs logiques (Fig. 2.7). Chacun de ces blocs permet de réaliser une ou deux fonctions logiques avec quelques variables à travers une LUT ("Look Up Table"). Il contient un registre de sortie pour stocker éventuellement le résultat du calcul. Les FPGA possèdent d'autre part des blocs entrée/sortie connectés de manière programmable aux blocs logiques. L'ensemble de ces blocs logiques est interconnecté de façon régulière et programmable. L'outil de conception permet de placer l'ensemble irrégulier de fonctions logiques que constitue une application sur le FPGA, sur une structure physique régulière. La description de l'application peut être réalisée par un outil graphique, pour des complexités faibles (jusqu'à environ 5000 portes), ou avec des langages tels que VHDL ou Verilog.

Une caractéristique associée aux FPGA récents est intéressante dans les applications de traitement d'images : la possibilité de configurer et d'implanter de la mémoire RAM dans les blocs logiques. La part occupée par les blocs mémoires embarqués de type RAM tend à s'accroître fortement sur les nouvelles générations telles que les Virtex de Xilinx (Fig. 2.7) ou l'Apex d'Altera.
<figure><img src="image_31.png" /><figcaption>FIG. 2.7 – *Structure d’un FPGA type Virtex Xilinx*</figcaption></figure>

### 2.1.3.2 Circuits non programmables : ASIC

Ces circuits (Application Specific Integrated Circuit), sont contemporains des FPGA puisqu'ils sont apparus vers le début des années 80. Ce terme regroupe en fait plusieurs familles : les circuits personnalisables par masque parmi lesquels les réseaux prédiffusés (gate array) ou les circuits précaractérisés.

Dans le cas des réseaux prédiffusés, le fondeur fabrique en attente un ensemble de transistors dispersés de telle sorte qu'il est possible, par métallisation ultérieure, de disposer par la suite des portes interconnectées pour obtenir le fonctionnement souhaité. Le fondeur propose un ensemble de taille variable, tant en nombre de portes fondamentales réalisables, qu'en nombre de buffers d'entrée/sortie.

En ce qui concerne les circuits précaractérisés, le fondeur réalise son circuit par assemblage de composants précaractérisés. Un des premiers inconvénients lié à cette famille de circuits est le temps de conception. En effet, chaque implantation fournie au fondeur est onéreuse et doit être vérifiée par simulation et à plusieurs reprises, car l'implantation est irréversible. Le succès de cette famille s'explique par le fait que chaque concepteur dispose d'un large choix de produits répondant chacun à des impératifs techniques et commerciaux. Les ASIC sont particulièrement adaptés aux grandes séries.

### 2.1.3.3 SoC (System On Ship)

#### Les IP (Intellectual Property)

La capacité de conception des circuits spécialisés augmente rapidement grâce aux logiciels de développement de plus en plus performants, mais dans un rapport trois fois moindre que l'augmentation des capacités d'intégration. On constate ainsi [LW02] que le délai moyen de conception d'une application sur composants dédiés reste d'environ une année. Il est donc impératif de réutiliser les conceptions déjà réalisées. Pour cela, des blocs
de base, couramment appelés IP (intellectual property), sont rendus disponibles à partir
de bibliothèques. Ces IP sont directement utilisables dans le logiciel de développement,
leur assemblage permettant de décrire rapidement des applications complexes.

On peut utiliser des IP sans les avoir conçu, en ayant uniquement une description haut-
niveau de leur comportement (vue externe fonctionnelle) : c'est pourquoi le commerce des
IP s'est considérablement développé ces dernières années.

Les IP peuvent être paramétrables et décrits en langage haut niveau tel VHDL ou Verilog (on parle alors de SoftIP), ou bien dépendant d'une technologie très optimisée (HardIP).

Les SoC et les SoPC

Grâce aux progrès importants de l'intégration, on voit apparaître des implantations de plus en plus complexes visant à intégrer dans un seul composant plusieurs entités qui auparavant constituaient des composants à part entière.

Tant que l'on reste sur une puce, les distances à parcourir sont courtes et les capacités mises en jeu sont faibles. En revanche, dans un contexte multi-composants, les temps de propagation et la puissance dissipée sont plus importants lors des transferts et limitent les performances. Par exemple, les processeurs rapides fonctionnant à 2 GHz ne peuvent au mieux communiquer qu'à la fréquence de 400 MHz. L'intégration des systèmes dans un seul composant autorise des communications rapides et ceci avec de faibles consommations. Il est donc préférable d'utiliser un gros composant constitué de plusieurs sous-systèmes, que plusieurs systèmes intégrés dans plusieurs composants et reliés entre eux sur une carte. Une conséquence directe en est la simplification des routages sur les cartes électroniques.

Le concept de SoC est lié à une méthode de conception pour l'intégration de gros systèmes basée généralement sur des IP. La réutilisation de blocs IP dans le développement du système permet d'accroître considérablement sa rapidité. L'essentiel du travail réside alors dans le découpage fonctionnel du système de base, et éventuellement dans la définition de blocs non disponibles sous forme d'IP.

L'approche de SoC a été créée dans un premier temps pour le développement d'ASIC mais a été étendue pour le développement de FPGA, on parle alors parfois de SoPC, pour "System on Programmable Ship". Le principe de conception est identique et l'on confond régulièrement ces deux termes dans la pratique.

Les cœurs de processeurs

Étant donné qu'il est possible d'implanter des mémoires et des unités de calcul dans les FPGA et les ASIC, les fournisseurs de processeurs standard ou de DSP proposent des cœurs de processeurs, sous forme d'IP, pouvant être intégrés dans des composants dédiés.

Ces cœurs de processeurs sont programmables en C par l'intermédiaire-d'OS temps réel (Part. 2.2.2). Xilinx propose par exemple un cœur IBM PowerPC pour Virtex II Pro, programmable à l'aide de l'OS temps réel VxWorks. Chez Altera, ce sont des blocs DSP, processeurs dédiés au applications de traitement du signal, qui sont proposés (Fig. 2.8). L'environnement de programmation "DSP builder" fourni permet de développer, simuler et vérifier les applications à implanter sur le bloc DSP sous Matlab et Simulink, puis de réaliser leur synthèse avec les outils classiques pour FPGA.

L'utilisation d'un ASIC donne la possibilité d'utiliser un plus grand nombre de DSP sur une même puce, et donc de paralléliser les calculs. Les SoC couplent la souplesse des
<figure><img src="image_32.png" /><figcaption>FIG. 2.8 – Bloc DSP chez Altera.</figcaption></figure>

processeurs aux performances de pointe des composants dédiés.

Un avantage de l'implantation d'un DSP sur un FPGA est la possibilité de réaliser des accès parallèles à de nombreuses endroits de la mémoire, alors que le nombre restreint de bus dans un DSP limite la bande passante mémoire. D'autre part, un cœur de processeur peut être configuré de plusieurs manières afin de correspondre au mieux à l'application visée. Il est envisageable d'utiliser plus de ressources (tailles des registres, des bus et des ALU) pour plus de performances, ou moins de ressources pour économiser de la place sur le composant.

### 2.1.4 Comparaisons des différents circuits spécialisés

La conception d'une application avec des composants dédiés nécessite de longs temps de développements, cela malgré les environnements de programmation de plus en plus fonctionnels et le développement des blocs IP. De plus, les équipes de développement doivent être de plus en plus conséquentes et compétentes, de part l'utilisation de nombreux outils, langages de programmation et composants. Le coût global ne peut être rentabilisé que sur des moyennes séries dans le cas de FPGA, et grandes séries pour les ASIC.

Nous avons pu voir que les architectures des processeurs standard et des DSP ont beaucoup évolué ces dernière années, et que les composants spécialisés peuvent intégrer des cœurs de processeurs pour plus de flexibilité. La frontière entre ces deux familles, à l'origine si distinctes, est de plus en plus floue. L'étude des performances intrinsèques, des consommations et des temps de développement pour chacune de celles-ci permet de fixer des ordres de grandeur pour faire un choix parmi elles [Aub98].

Pour donner un ordre d'idée des performances de ces FPGA, un calcul spécifique comme une transformation de Fourier par un algorithme rapide FFT 256 points est réalisé en 1 microseconde sur un Virtex II Xilinx (110 MHz), valeur que l'on peut comparer à celles données figure 2.6.

Au niveau des performances des cœurs de processeurs, une FFT sur 1024 points est annoncée en 53 microsecondes pour une fréquence de 98 MHz sur un cœur de DSP implanté sur FPGA Altera : c'est-à-dire 13,25 microsecondes pour 256 points. La performance à fréquence égale est donc bonne pour les cœurs de processeurs, mais le temps global du
calcul reste important à cause des faibles fréquences mise en œuvre. La fréquence étant d'environ 200 MHz pour un ASIC et 110 MHz pour un FPGA, on aura toujours de moins bons résultats avec un cœur de DSP qu'avec un DSP "classique".

En ce qui concerne les temps de développement, les fournisseurs de composants travaillent énormément afin de fournir des circuits facilement programmables. Ceci passe par des environnements de programmation soignés au niveau ergonomie, mais aussi par la création des compilateurs puissants qui projettent des algorithmes développés à un haut niveau d'abstraction (en langage C ou Matlab pour les processeurs, et en VHDL pour les circuits dédiés) en utilisant de manière optimale les ressources du composant. Pour les calculs critiques, des bibliothèques adaptées doivent être utilisées, on parle d'IP dans le domaine des composants dédiés. Elles sont généralement développées par des spécialistes du composant et fournies avec celui-ci ou par des entreprises spécialisées. Le développement sur matériel dédié reste toujours plus long et plus complexe que sur les processeurs standard ou DSP.

Quant aux développements d'applications Mpeg, les contraintes temps réel des décodeurs sont facilement satisfaites sur un unique composant. Des logiciels de décodage Mpeg-2 pour processeurs standard sont disponibles depuis longtemps et intégrés dans la quasi totalité des outils de visualisation.

Dans le domaine des DSP, la société Ateme propose depuis décembre 2001 un décodeur Mpeg-2 vidéo logiciel spécialement mis au point pour la famille de DSP C6000 de Texas Instruments. Cette approche permet notamment au développeur d'intégrer d'autres fonctions sur le même processeur (audio, transmission, par exemple) et d'optimiser le rapport coût/performance. A titre d'exemple, le décodage vidéo Mpeg-2 d'un flux à 1.5 Mbit/s au format CIF couleur charge à 50% un DSP C6211 (150 MHz). Le décodage d'un flux Mpeg-2 à 8 Mbit/s au format plein écran couleur occupe quant à lui 98 % du temps CPU d'un DSP C6203 (300 MHz). Ateme propose par ailleurs d'adapter sa solution à la demande en fonction des contraintes d'entrée/sortie ou des contraintes mémoires. La principale difficulté des applications Mpeg est l'importance des données à traiter. Le fait que les décodeurs Mpeg-2 pour DSP soient récents, alors que le standard reste figé depuis une dizaine d'année, illustre cette difficulté.

Les codeurs ont beaucoup plus de calculs à réaliser qu'un décodeur, en particulier avec les opérations d'estimation de mouvement, ce qui rend le temps réel difficile à obtenir. Les applications de codage DivX, comparables en complexité aux algorithmes Mpeg-4, traitent environ 10 images par seconde sur des processeurs standard récent. Des applications logicielles de magnétoscope numérique sont alors impossibles. La société Envivio propose le premier encodeur Mpeg-4 capable d'une résolution de qualité DVD. La plate-forme utilise des serveurs dotés de processeurs Intel Xeon dernière génération, ainsi que des PC possédant des processeurs Intel Pentium 4. La réalisation d'applications de "streaming" (codage, émission, réception et décodage temps réel de flux Mpeg-4), font leur apparition.

Il est possible de trouver de nombreux composants dédiés permettant de réaliser des parties d'algorithmes Mpeg-2. Avec les progrès de l'intégration, on peut dorénavant trouver des composants dédiés au codage des séquences au format Mpeg-2 vidéo, sous certaines restrictions. Dans le domaine des DSP, il n'existe pas de telle possibilité. Les applications dans le cadre de l'embarqué restent encore très limitées aujourd'hui.
L'emploi d'architectures complexes intégrant plusieurs unités de calcul est nécessaire pour atteindre le temps réel. Nous allons développer les différentes possibilités d'architectures multi-composants qui peuvent être employées.

### 2.1.5 Architectures multi-composants

Une solution pour accélérer les temps de calcul est de partager ces opérations sur plusieurs composants. Même si l'idée est simple et depuis longtemps mise en pratique, la mise en place d'une telle architecture est plus complexe et onéreuse. Au prix des composants vient s'ajouter celui du développement des cartes reliant les différents composants sur un même support. Une autre solution consiste en l'utilisation de plusieurs cartes connectées par des liens de communications standard (PCI ou Ethernet par exemple), ou encore, avec l'émergence des SoC, en l'intégration de plusieurs unités de calcul sur un même composant. Nous verrons premièrement les différents types de réalisations multi-composants qui peuvent être mis en œuvre, puis les caractéristiques liées aux développements d'applications sur de tels systèmes.

#### 2.1.5.1 Architectures multi-processeurs

Lorsqu'une application ne peut être implantée sur un unique DSP, il est naturel de penser à l'utilisation de plusieurs DSP. Les fournisseurs comme Analog Device avec l'ADSP 2106x ou Texas Instruments avec les TMS320C4x proposent des composants simples à connecter entre eux sur une même carte. Des sociétés commercialisent de telles cartes, en y associant des solutions afin de contrôler les DSP et leurs communications.

Adaptive Solutions Inc. propose le CNAPS SIMD multiprocesseur : un séquenceur CNAPS peut être couplé avec un ou plusieurs processeurs CNAPS, contenant chacun jusqu'à 64 processeurs virgule fixe.

Plusieurs processeurs peuvent être intégrés dans un seul composant. En 1994, Texas Instruments a introduit le TMS320C8x qui contient 4 DSP virgule fixe et un processeur RISC. Cette solution n'a pas été un succès commercial, car le compilateur associé au DSP n'était pas simple à manipuler et seul un spécialiste du composant pouvait tirer parti de cette architecture complexe.

La conception SoC permet désormais de développer des systèmes multi-DSP rapidement. Xilinx annonce pour la deuxième moitié 2003 un circuit qui intégrera 4 cœurs de processeurs PowerPC cadencés à 300 MHz.

#### 2.1.5.2 Architectures multi-FPGA

Les cartes multi-FPGA peuvent être utilisées pour faire du prototypage d'ASIC [Ele01b]. Les fabricants de cartes multi-FPGA se sont associés aux fournisseurs de FPGA de développer une telle possibilité. Le logiciel de synthèse Certify, de Synplicity permet le partitionnement automatique de l'application sur plusieurs DSP, selon des spécifications prédéfinies sur la carte. De plus, une fonction "multiplieur de broches" a pour but de n'utiliser une seule broche d'entrée/sortie pour transmettre des signaux multiples entre circuits. Ce logiciel permet selon Synplicity de réduire à quelques heures, au lieu de quelques jours
ou semaines habituellement, le développement d'ASIC fonctionnel avec une carte de prototypage standard d'un des partenaires du développement. Le logiciel Certify est sur le marché depuis l'été 2002.

Cette technique de prototypage d'ASIC à partir de cartes multi-FPGA est extrêmement pratique car elle réduit les temps de développement et surtout de tests qui précèdent le prototypage d'un ASIC. Les communications entre les FPGA sont rendues possibles par l'utilisation de ressources adaptées mettant en place un protocole de communication. Ces ressources seront également implantées sur l'ASIC final, ce qui diminue sensiblement les performances.

### 2.1.5.3 Architectures hétérogènes

Une solution très répandue pour accélérer les temps de calcul s'opère par l'association à un processeur standard ou un DSP, d'un co-processeur dédié, qui sera soit un ASIC, soit un FPGA [SW97]. On parle alors d'architectures mixtes (Codesign) du fait de la nature différente des unités de calcul. Ainsi, les calculs les plus répétitifs et élémentaires sont pris en charge par la partie dédiée, et les parties nécessitant plus de souplesse (exécutions conditionnelles, allocations dynamiques ...) par le(s) processeur(s). Une fois le choix de la répartition des calculs effectué (généralement uniquement grâce à l'expérience des développeurs), différentes équipes vont prendre en charge la réalisation de l'implantation. Ensuite, il s'agira de réunir le travail de chaque équipe pour l'implanter sur la plate-forme mixte. Sur de plus petits projets, ces tâches seront accomplies par une seule personne, qui devra alors maîtriser l'ensemble de la chaîne de développement.

Typiquement, le programme de la partie non-dédiée fait appel pour la réalisation des fonctions critiques à la partie dédiée. Il faut alors gérer les communications entre les composants différents pour envoyer les données, puis attendre le résultat avant de continuer les calculs. Les calculs très répétitifs sont exécutés bien plus rapidement sur la partie dédiée, le temps global de calcul en est alors diminué. On voit cependant que cette solution peut être améliorée en continuant les calculs sur la partie non-dédiée pendant le calcul de la fonction critique.

### 2.1.5.4 Réalisations Mpeg multi-composants

L'implantation temps réel des normes Mpeg-1 et Mpeg-2 a longtemps eu recours à des implantations spécifiques [PDG95].

Les réalisations Mpeg multi-composants concernent les applications de codage, du fait de leur complexité importante. [PTB+92] donne dès 1992 un exemple de codeur composé de 7 circuits spécifiques. L'estimation de mouvement, la DCT, les quantifications directe et inverse, le codage VLC ainsi que le contrôle faisaient chacun l'objet d'un circuit dédié. Aujourd'hui, les exemples d'implantation sur un seul circuit de codeur ou de décodeur Mpeg-2 temps réel au format "Main@Main" ne manquent pas, ces circuits intègrent des blocs spécifiques ainsi qu'un cœur programmable. Les progrès de l'intégration permettent maintenant d'intégrer trois décodeurs complets sur un même circuit [Ele02]. Grâce à cela, il est possible d'enregistrer simultanément deux programmes diffusés en direct tout en regardant l'un ou l'autre, de faire une pause et de reprendre la lecture en différé à partir du même point.
Pour allier performance et programmabilité, de nombreuses solutions hybrides à mi-
chemin entre le matériel dédié et le tout programmable ont également vu le jour sous le
nom de média processeurs [Sor99]. Le média processeur peut être défini comme un circuit
programmable contenant un processeur et des fonctions de décodage audio et vidéo, de
traitement graphique, de contrôle et de communication intégrés dans des co-processeurs
spécifiques. Nous pouvons citer par exemple le processeur Trimedia de Philips.

2.1.6 Complexité de mise en œuvre

Les applications élaborées sur des systèmes multi-composants ont été élaborées de manière à utiliser au mieux les différents éléments de ces systèmes. La première tâche à réaliser est la répartition des calculs sur les éléments programmables de la plate-forme. Ensuite, l'équipe de conception devra programmer chacun des composants en apportant un soin particulier à la synchronisation des calculs, à la mise en place des systèmes de communication et des transferts de données entre les composants. Ces problèmes sont d'autant plus critiques que chacun des composants possède souvent ses propres outils de description. Bien souvent, l'ensemble de ces actions est réalisé manuellement par l'équipe de conception, dans laquelle on retrouve des spécialistes de chaque composant. La répartition des développements au sein de l'équipe doit être faite avec vigilance afin de limiter les risques lors de la mise en commun des développements réalisés sur chacun des composants.

De part sa complexité, un système matériel qui intégrerait autant de blocs dédiés que Mpeg-4 comporte d'”outils” n’est pas prêt de voir le jour. De plus, ce système serait sous optimal, dans la mesure où il conduirait nécessairement à une sous-utilisation de ses composants. Le ”tout spécifique” n’a ici pas de sens et la part du logiciel dans un terminal Mpeg-4 est et restera importante.

Les systèmes multi-composants sont des solutions couramment employées pour accélérer
les temps de calculs. Cependant, les temps de développement de ces systèmes restent longs
et doivent être diminués pour plus de rentabilité. Pour cela, l'hétérogénéité de l'architec-
ture doit être transparente pour le concepteur. L'utilisation de langages haut-niveau, de
bibliothèques spécialisées et d'IP participent à cet effort. Pourtant, le prototypage tota-
lement automatique d'une architecture complexe à partir d'une description haut-niveau
des fonctionnalités de l'algorithme n'est pas encore de mise. Cet objectif est pourtant in-
dispensable afin de rendre viables les futurs composants constitués de plusieurs unités de
calcul.

D'autre part, on observe trop souvent une utilisation sous-optimale des ressources
des architectures hétérogènes. Une partie dédié sert de co-processeur (avec un processeur
standard ou un DSP). Le programmeur, après avoir implanté la totalité des algorithmes
sur le processeur va vouloir délester ce dernier des calculs les plus intenses en utilisant la
partie dédiée. Plutôt que de lancer ce calcul sur le processeur, il va envoyer les données sur
la partie dédiée qui va pouvoir effectuer le calcul. Le processeur sera alors dans l'attente
du résultat alors qu'il pourrait effectuer d'autres opérations. L'accélération du calcul se
voit alors diminuée.
## 2.2 Systèmes temps réel de traitement des images

Le domaine du traitement du signal et des images est un domaine particulièrement complexe de l'électronique puisqu'il nécessite d'excellentes performances de calcul associées à une flexibilité importante. De nombreuses applications possèdent de fortes contraintes de temps imposées. De plus, l'évolution des applications dans le domaine de l'embarqué tend vers l'intégration de systèmes multimédias dans des produits comme les téléphones portables ou les PDA, constitués de plusieurs unités de calcul. Pour de telles applications, l'utilisation de toutes les ressources disponibles sur la plate-forme est nécessaire pour fournir des résultats visuels acceptables. La programmation d'architectures multi-composants est donc requise et doit être optimisée.

Le domaine du temps réel embarqué est particulièrement vaste et d'un poids économique considérable, puisqu'il regroupe des applications dans les processus de contrôles, dans l'automobiles, l'aviation, la défense, les télécommunications, le médical, le multimédia et bien d'autres secteurs d'activités. A cet effet, on peut citer le système de contrôle du trafic aérien américain [Sta]. Ce système estimé à plus de 5 milliards de dollars, est basé sur un programme de 1 à 2 millions de lignes de code, possède quelques centaines de consoles, et doit répondre à des contraintes de temps allant de quelques minutes, pour les demandes de réservation de billets par exemple, à quelques millisecondes pour les informations de contrôle aérien. Les estimations attribuent quelques 2000 milliards de dollars dépensés dans les outils, applications, et systèmes d'exploitation temps réel. Pour évaluer de manière plus simple l'importance du temps réel embarqué, il existe mille fois plus d'ordinateurs embarqués que d'ordinateurs personnels. De nombreux axes de recherche peuvent être traités, comme la recherche de performances garanties, les vérifications de résultats, les langages de programmations, ou encore l'évolution du système au fil du temps.

Les applications multimédias s'inscrivent souvent dans le domaine des applications temps réel embarquées que nous allons maintenant décrire, avant de présenter la solution de programmation généralement utilisée pour de tels systèmes, i.e. la mise en œuvre de systèmes d'exploitation temps réel (RTOS).

### 2.2.1 Exécutif temps réel embarqué

Nous décrivons ici les termes "exécutif", "temps réel" et "embarqués" afin de mieux cerner les limites de ce domaine.

#### 2.2.1.1 Exécutif

Que ce soit un processeur standard ou un DSP, les fournisseurs livrent des logiciels spécialisés pour créer les applications. Le concepteur peut y décrire son application, l'outil se chargeant de créer l'exécutif adapté au composant par le processus de compilation.

L'exécutif est l'ensemble des instructions bas-niveau nécessaires à la gestion du processeur et de ses périphériques (mémoires, timers, DMA par exemple). Pour chaque composant, le fournisseur livre un logiciel de compilation qui permet, à partir de la description d'une application, de générer un exécutif adapté au processeur cible.

Le système d'exploitation (operating system - OS) est un ensemble de services permettant le contrôle de l'exécution des différents exécutifs sur une machine, ou encore la
gestion des fichiers. Un système d'exploitation temps réel (real-time operating system - RTOS) est alors une version d'OS adaptée au domaine du temps réel.

### 2.2.1.2 Temps réel

Les applications temps réel sont des systèmes réactifs, c'est-à-dire qu'elles réagissent à leur environnement physique avec de multiples entrées permettant l'observation de l'environnement, et de nombreuses sorties pour agir sur celui-ci. La caractéristique du temps réel est de considérer toute réponse fournie en dehors d'une fenêtre temporelle comme fausse, et ce quelle que soit sa valeur.

Généralement, les contraintes pour la réalisation de ces applications sont :

- Une **solution à composantes parallèles** (prise en compte des événements asynchrones). Lorsque plusieurs entrées du système évoluent, celui-ci doit pouvoir déclencher plusieurs actions simultanément. Il s'ensuit un certain parallélisme des calculs que doit gérer le système.

- Un **partage du processeur** lorsque le nombre de processeurs est moins important que celui de fonctions à réaliser. Si le système possède plus de tâches à exécuter simultanément sur une même unité de calcul, il doit organiser le séquencement de ces calculs de manière à satisfaire toutes les contraintes de temps.

- Une **exécution de fonctions synchrones aux événements externes** (interruptions). Si, pendant que le système est en train d'exécuter une tâche, une entrée du système vient à changer et nécessite une prise en compte immédiate et prioritaire à l'action en cours, le système doit accomplir cette nouvelle tâche avant de reprendre la tâche interrompue.

- Des **contraintes de temps à satisfaire**. Cette notion de contrainte de temps varie énormément en fonction des applications. Il va de soi que le problème peut devenir critique si la commande d'un pilote de chasse n'est pas transmise instantanément aux actionneurs de l'avion. Nous sommes ici dans du temps réel dit **strict** (ou **critique**), caractérisé par des conséquences dramatiques en cas de non respect des contraintes. En revanche, certains systèmes temps réel, comme le contrôle d'une carte banquaire dans un distributeur de billets, sont dit **souples** et sont caractérisés par une certaine tolérance de non respect des contraintes. Les critères de temps peuvent être la fréquence de sortie ou d'entrée (débit), le temps de réponse (latence, c'est-à-dire la durée entre l'arrivée d'une entrée et l'obtention du résultat correspondant en sortie) ou encore la cohérence de sorties (temps qui sépare les instants d'évolution de deux sorties suite au traitement d'une nouvelle entrée) ou d'entrées.

### 2.2.1.3 Embarqué

Les contraintes liées à l'électronique embarquée sont :

- Le **coût**. Chaque produit doit être conçu pour un segment donné du marché, c'est-à-dire une fourchette de prix pour des fonctionnalités attendues. Si le coût
de développement devient trop élevé, les fonctionnalités ainsi que les performances doivent être revues également à la hausse.

- **Le temps de développement.** En plus des contraintes de temps de développement de l'architecture du système, il faut prendre en compte le temps de développement des fonctions logicielles associées.

- **La dissipation de puissance.** La dissipation est directement reliée à l'autonomie du système embarqué.

- **Les contraintes physiques.** Les contraintes de taille et de poids par exemple nécessitent l'utilisation de batteries de faible capacité, ce qui est a priori incompatible avec de longues autonomies.

Des choix doivent donc être réalisés pour privilégier un ou plusieurs de ces critères. Par exemple, pour un ordinateur portable, l'autonomie est souvent négligée par rapport aux contraintes de performances et de taille. En effet, un ordinateur peu performant perd tout son intérêt, d'autant plus qu'il est souvent possible de travailler à proximité d'une prise de courant. Pour un téléphone portable au contraire, l'intérêt étant de pouvoir téléphoner de partout, l'autonomie est un critère primordial. Tout en tenant compte de ses contraintes, une architecture cible est déterminée à partir des éléments présentés en début de ce chapitre.

Dans tous les cas, les ressources de l'architecture choisie doivent être économisées un maximum : les calculs doivent être optimisés, la place des données et des programmes minimisée. La miniaturisation et les gains en puissance des unités de calcul permettent de plus en plus de répondre à ces attentes, mais les besoins augmentent énormément et les futures applications nécessiteront encore une gestion optimisée des ressources pour être viables dans un contexte embarqué.

## 2.2.2 Systèmes d'exploitation temps réel

La construction d'un exécutif temps réel embarqué n'est pas chose aisée [Dem01]. De nombreux choix doivent être faits a priori, comme celui du ou des composants à utiliser, avant la phase de développement proprement dite. Dans le domaine du temps réel, les développements sont généralement aidés par l'utilisation des RTOS ("Real-Time Operating System"), systèmes d'exploitation temps réel. Depuis quelque temps, ces solutions commerciales offrent la possibilité de programmer des plate-formes multi-composants. Le concepteur doit alors centrer son travail sur les fonctionnalités de l'application et sur l'efficacité des calculs. L'utilisation du RTOS permet de s'affranchir un maximum des contraintes matérielles.

### 2.2.2.1 Notion de tâche

Grâce aux systèmes d'exploitation temps réel, il est possible de créer plusieurs applications sur un même processeur, chacune de ces applications pouvant être divisée en tâches. Chaque tâche réalise une opération donnée. Le RTOS permet de définir une priorité à
ces tâches de manière structurée, d'effectuer la gestion des temps, la fréquence des appels aux tâches et la gestion de communication entre ces tâches. Plusieurs tâches peuvent ainsi s'exécuter simultanément sur un même processeur (multitâches), comme si chacune d'elles était exécutée sur un processeur différent. En contre-partie de ce pseudo parallélisme d'exécution, des mécanismes de mémorisation doivent être créés afin de sauvegarder le contexte de chaque tâche entre deux exécutions réelles. Ces mécanismes constituent alors des surcoûts spatiaux et temporels.

### 2.2.2.2 Synchronisations

L'exécution de calculs en parallèle ne peut être réalisée sans système de synchronisation. Le bon fonctionnement de l'application est conditionné par l'ordre d'exécution des calculs. Le système doit mettre en place des systèmes d'attente passive et active. L'attente passive laisse la possibilité à d'autres calculs d'être exécutés pendant l'attente. L'attente active quant à elle bloque l'exécution de la tâche et des autres de priorités inférieures. Le choix de l'une ou l'autre des techniques doit être opéré afin de garantir l'ordre d'exécution des calculs, et d'éviter le blocage de l'application.

Il est aussi possible d'utiliser le système des interruptions. Une tâche peut être interrompue par une autre de priorité supérieure, et reprise lorsque la tâche de priorité supérieure est terminée.

<figure><img src="image_33.png" /><figcaption>FIG. 2.9 – Réseau de Pétri d'une application multi-tâches synchronisée par sémaphore.</figcaption></figure>

L'utilisateur du RTOS, pour réaliser des synchronisations, peut utiliser des sémaphores. Le formalisme de description le plus courant pour les applications multi-tâches synchronisées par sémaphore est celui des réseaux de Pétri (Fig. 2.9). Un réseau de Pétri est constitué de *places* et de *transitions*. Chaque *place* constitue un ensemble d'opérations à réaliser, correspondant pour nous à des calculs spécifiques (sous forme de fonctions). Les *transitions* déterminent l'enchaînement des différentes *places*.
Les sémaphores peuvent être assimilés à une case comportant un jeton qu'une tâche peut prendre ou fournir. Si une tâche doit prendre le jeton, elle attend que ce jeton soit positionné dans le sémaphore, à un autre instant dans la même tâche ou par une autre tâche de l'application. L'attente peut être passive ou active, le sémaphore peut mettre en œuvre un ou plusieurs jetons dans une même case. Des mécanismes complets de synchronisation à base de sémaphores comme les rendez-vous, qui permettent à deux tâches de s'attendre mutuellement à un instant précis de leur exécution, sont proposés par le RTOS.

Le mécanisme de sémaphore est dit avec mémorisation puisqu'il peut y avoir un certain temps entre le positionnement d'un jeton et sa consommation. Un mécanisme de synchronisation sans mémorisation est celui des événements : l'envois d'un événement aboutit à l'exécution d'une tâche instantanément ou n'a aucun effet si cette tâche ne peut être exécutée à cet instant (si une autre tâche plus prioritaire est exécutée par exemple).

### 2.2.2.3 Partage des données

Plusieurs techniques permettent aux tâches d'une application de communiquer. L'utilisateur peut utiliser les mécanismes de diffusion de messages, d'attente avec chien de garde, ou encore de boîte aux lettres.

Une zone critique peut être une structure de donnée, une ressource partagée, une section de code avec contrainte de temps précis, ou encore une zone mémoire que l'on ne peut lire/modifier/utiliser que par une tâche à la fois. Ces zones ne doivent pas être gênées par des interruptions par exemple. Le RTOS permet la gestion de ces zones critique, par la mise en attente d'interruption, ou la mise en place de verrous à base de sémaphores (relation de synchronisation) couplée à l'inhibition d'interruption lorsqu'une tâche doit accéder à ces zones.

Les ressources partagées (ports d'entrée/sortie, affichage, données) peuvent être utilisées par plusieurs tâches. La gestion des ces ressources est gérée par le RTOS.

Le partage des données est plus complexe dans le cas multi-processeurs puisque plusieurs composants peuvent accéder à des ressources comme des mémoires par des bus communs. Les zones critiques sont alors bien plus nombreuses et complexes à gérer.

### 2.2.2.4 Ordonnancement

L'ordonnancement d'un algorithme sur une architecture est un problème d'allocation de ressources. Deux grandes catégories d'allocations peuvent être utilisées [CK96] : dynamique ou statique.

#### L'allocation dynamique

L'allocation dynamique est efficace lorsque la durée d'exécution dépend de la donnée traitée. La gestion dynamique des ressources est plus souple, allouant des espaces mémoire et créant des systèmes de communication au fur et à mesure du traitement des données. Elle permet également une activation aléatoire des diverses tâches en fonction d'éléments extérieurs.

En revanche, le prix à payer est une perte d'efficacité [BLMV98, SAK95, LB90] due à une taille de programme et un temps d'exécution plus longs. De plus, les changements
de contextes et les routines de communication dynamiques ne permettent que très difficilement de prédire les temps d'exécution et les ressources nécessaires à chaque instant. Le concepteur doit alors prévoir des marges de sécurité, afin que les ressources nécessaires lors de l'exécution du programme ne dépassent à aucun moment les ressources du système, et pour que contraintes de temps soient respectées.

### L'allocation statique

En ce qui concerne l'ordonnancement statique, il permet de minimiser le temps d'exécution [BLMV98, Ern98], et les ressources nécessaires, car ils sont totalement prévisibles. En contrepartie, toutes les applications ne peuvent être prise en charge, spécialement celles qui dépendent d'un environnement inconnu au moment de la compilation. L'exécutif statique est adapté [LB90] aux applications temps réel [BB94] sur machines embarquées (et obligatoire pour du temps réel strict), pour lesquelles les ressources et les temps d'exécution sont connus précisément, que ce soit pour du contrôle de process, du traitement du signal, ou d'images.

Une partie importante des recherches sur les ordonnancements statiques vise à minimiser les communications inter-processeurs [KLZ97, YG93, LHF91], mais porte rarement les optimisations (organisation, placement [Wan91] et parallélisme). Celles-ci peuvent être statiques à partir du moment où l'on peut allouer les séquences de communications, l'important étant de pouvoir prédire de manière précise ces temps de communication [SAK95]. Basée sur ces observations, la méthodologie AAA (Adéquation Algorithme Architecture [GLS99, Gra00]) permet de générer automatiquement un processus statique optimisant le placement et le parallélisme des actions sur plate-forme hétérogène. Tous les calculs sont activés de manière déterministe.

L'utilisation d'un RTOS commercial induit automatiquement la présence d'exécutifs dynamiques. Cette utilisation génère un surcoût non négligeable en termes de taille de code, puisque celui-ci utilise environ 20% de la mémoire interne d'un DSP récent. Les RTOS sont appropriés dans les cas où plusieurs tâches concurrentes doivent se partager les ressources, mais où les contraintes de temps par rapport aux possibilités des DSP ne sont pas trop importantes.

### 2.2.2.5 Communications inter-processeurs

Les communications entre composants doivent être mises en place. Pour envoyer une donnée, il faut que le processeur émetteur prépare les données, demande au récepteur si il est disponible pour recevoir les données, et, si c'est le cas, effectue le transfert. Le processeur émetteur doit finalement être averti de la fin du transfert par le récepteur. Les RTOS utilisent leurs systèmes de synchronisation de partage de données pour réaliser des protocoles de communication inter-processeurs. L'utilisation d'un RTOS rend alors ces opérations transparentes pour l'utilisateur qui doit uniquement positionner les systèmes de partage des données entre les tâches. Le RTOS utilisera son protocole de communication uniquement dans le cas où ces tâches sont sur des unités de calcul différentes. La gestion d'un système multi-processeurs se réduit alors à la description des différentes tâches d'une application et leurs niveaux de priorité, des systèmes de partage des données, comme dans le cas mono-processeur, puis au positionnement de ces tâches sur les unités de calcul disponibles.
### 2.2.2.6 Répartition (ou placement) des calculs

Dans l'élaboration d'un système multi-composants, la répartition des calculs sur les différentes unités disponibles est un problème complexe que l'on peut diviser en quatre catégories [Cal98]:

- Le partitionnement fonctionnel. Cette étape consiste à définir une architecture fonctionnelle capable de réaliser les différents calculs en connaissant les spécifications de l'application. Il s'agit en définitive de décrire les différentes fonctions nécessaires à la réalisation de l'application.

- Le partitionnement géographique. Il s'agit ici de définir les distances entre les unités de calcul en fonction de contraintes externes comme la localisation des entrées et des sorties. La distance entre les unités de calcul peut être très faible si le système est réalisé sur une même carte, mais peut également être très importante si des systèmes de communication permettent des échanges (Internet, satellite).

- L'architecture des ressources permet de localiser les ressources nécessaires aux calculs. A cette étape, la plate-forme est modélisée sous forme de ressources (sans détails quant aux fonctionnalités de communications) et le logiciel associé sous forme de tâches utilisant ces ressources.

- L'architecture matérielle est finalement définie par le partitionnement matériel/logiciel décrivant le positionnement des différentes fonctions sur les unités de calcul, ainsi que les relations entre ces fonctions.

Cette division s'appuie sur le fait que l'architecture est conçue pour une application donnée, et qu'elle doit être au maximum adaptée aux contraintes de l'application.

Cependant, bien souvent, un traiteur d'images connaîtra un contexte différent : il vou-dra implanter son algorithme de manière optimale sur la plate-forme en sa possession. Le partitionnement géographique sera alors imposé, le principal problème consistera à posi-tionner les différentes tâches sur les unités disponibles. Malgré les outils des RTOS multi-composants, cette répartition sera faite manuellement et les choix basés sur l'expérience du concepteur.

### 2.2.2.7 Types de RTOS

On peut citer trois types de systèmes d'exploitations (temps réel ou non):

- Les OS résidents configurables. Ces OS sont chargés sur le (ou les) processeur(s) cible(s). Les services offerts par le système (nombre de tâches, priorités...) sont indépendants de l'application et peuvent alors être utilisés dans de nombreux do-maines applicatifs.

- Les OS résidents non configurables. Ces OS sont également chargés sur le (ou les) processeur(s) cible(s). Les services nécessaires à une application sont configurés dès le début de l'exécution et n'évoluent plus ensuite. Moins souples que la solution précédente, ces OS présentent des avantages en termes de taille et de performances.

- RTOS non résident (ou taillé sur mesure). Le principe est dans ce cas de fixer tous les paramètres lors de la compilation de l'exécutif de manière à ne pas embarquer l'ensemble des services possibles sur l'architecture cible mais uniquement ceux qui
seront nécessaires [GLS99, Gra00]). Le gain de place est une solution intéressante, spécialement pour le domaine embarqué, dans le cas où tous les paramètres sont connus et fixés lors de la compilation. Chaque nouvelle configuration doit faire l'objet d'une nouvelle compilation et d'un nouveau chargement du programme.

### 2.2.2.8 Exemples de produits commerciaux

Plusieurs produits commerciaux sont disponibles pour générer des exécutifs temps réel. L'offre dans ce domaine étant relativement importante (OSEK/VDX, RTEMS, TTP-OS ...), nous nous limiterons aux RTOS pour architectures multi-C6x, derniers DSP de chez Texas Instruments avec lesquels nous avons pu travailler.

Le premier est DSP/BIOS, l'OS gratuit fourni par Texas Instruments. DSP/BIOS est relativement limité et n'est pas utilisable pour du multi-DSP.

Nous pouvons citer OSE de chez Enea, mais également Virtuoso de chez Eonic (racheté par la compagnie VXWorks), ou encore 3L de chez Diamond.

La possibilité de réaliser un exécutif temps réel multi-composants est récente et actuellement, seules des plate-formes constituées de plusieurs composants identiques peuvent être mises en œuvre. Il reste encore aujourd'hui impossible d'utiliser les RTOS dans des configurations complexes intégrant des parties dédiées.

Les produits commerciaux présentés sont tous résidents. Ils sont adaptés au temps réel dans sa globalité, offrant pour toutes les applications le maximum de services.

## 2.2.3 Spécificités du traitement des images

L'exécutif temps réel embarqué est donc un programme comportant de multiples contraintes a priori contradictoires. De nombreux travaux se sont penchés sur le sujet et ont abouti à de réels progrès. Cependant, le temps réel embarqué possède encore de nombreux défis à relever et certains domaines de recherche restent encore sous-explorés [Sta]. Le traitement des images se situe parmi les systèmes orientés données et pose des problèmes spécifiques mêlant performances de pointe et flexibilité.

Pour mieux situer cette spécificité, nous allons la présenter parmi les quatre grandes classes de systèmes [JM98]:

- les **systèmes orientés calculs**, comme les stations de travail, PC ou réseaux d'ordinateurs,

- les **systèmes orientés contrôle**, qui réagissent aux contraintes externes par des actions relativement simples,

- les **systèmes orientés données**, où le problème réside en une transformation complexe ou dans le transport de données. Le traitement du signal et a fortiori le traitement des images entrent dans cette catégorie;

- les **systèmes mixtes**, comme les téléphones mobiles, qui doivent à la fois réaliser de nombreux calculs, et réagir aux événements extérieurs.

Les **graphes flots de données** sont très utilisés pour modéliser les systèmes orientés données comme les applications de traitement des images. C'est la raison pour laquelle les traiteurs d'images utilisent beaucoup le logiciel Simulink de chez MathWorks.
Un graphe flot de données est constitué de noeuds représentant des calculs, reliés entre eux par des arcs, symbolisant des données. La fin d'un noeud délivre des données (sorties) qui permettent d'activer un ou plusieurs noeuds possédant ces données en entrée. La mise en place d'un tel graphe se fait facilement à l'aide d'une interface graphique. Les calculs effectués dans les noeuds (opérations de filtrage par exemple) sont décrits par un langage de programmation, Matlab pour Simulink.

En comparaison, il existe également des **graphes flots de contrôle**, où les noeuds représentent des opérations, reliés entre eux par des arcs représentant des opérations de contrôle (comparaisons et autres tests). Ces graphes sont souvent utilisés pour la description de systèmes orientés contrôle.

Le **principal avantage dans l'utilisation d'un graphe flot de données** par rapport au graphe flot de contrôle se situe dans la phase de placement/ordonnancement des fonctions sur une architecture multi-processeurs. Dans un graphe flot de données, l'ordre d'exécution des noeuds est partiel, ce qui laisse la possibilité d'en exécuter plusieurs en parallèle. Le graphe flot de donnée permet de faire ressortir le parallélisme potentiel de l'application. En revanche, l'ordre d'exécution dans un graphe flot de contrôle est total. Par ce fait, il est nécessaire de réaliser une analyse de dépendance de données sur les variables manipulées par les différents noeuds d'un tel graphe pour une parallélisation des calculs. Cette opération est coûteuse et parfois trop complexe à réaliser ([Gra00]).

En ce qui concerne l'ordonnancement d'une application de traitement d'images, le choix doit être réalisé entre une approche dynamique et une approche statique. Si la mise en place d'une solution dynamique peut se révéler pratique et efficace dans la gestion des données et des calculs, elle ne permet pas de réaliser du temps réel strict et apporte des surcoûts spatiaux et temporels non négligeables [GLS99]. Les calculs intensifs nécessaires lors d'un codage ou d'un décodage vidéo dans le domaine embarqué temps réel ne peuvent alors être envisagés que par des processus statiques.

## 2.3 Méthodologies de conception de systèmes embarqués temps réel

L'utilisation d'une méthodologie de conception cohérente est d'une grande utilité pour développer des applications complexes, dans un contexte temps réel avec fortes contraintes. Elle aide dans un premier temps à organiser les différents acteurs du développement autour de l'objectif final, mais aussi à réutiliser automatiquement des travaux, ou des parties de travaux. Ainsi, le processus de développement devient plus rapide et peut s'affranchir des problèmes d'évolution et de complexité des composants, ce qui est crucial vu la complexité des applications futures. Il faut, dès le début d'un développement qui peut prendre plusieurs années, s'assurer que l'on puisse réagir aux évolutions prévisibles ou non.

Une méthodologie est aussi la base du développement d'outils d'aide au développement efficaces.

Le choix d'une méthodologie adaptée peut être également motivé par la possibilité de faire évoluer le travail réalisé pour plateforme multi-DSP vers des architectures mixtes (constituées de plusieurs processeurs et de composants dédiés) pour des performances accrues.
Nous présenterons MCSE, une méthodologie adaptée aux applications multi-tâches et son outil correspondant, Pegasus, adapté à la conception de systèmes multi-DSP, et enfin AVS/SynDEx pour la génération d'exécutifs statiques particulièrement performants.

### 2.3.1 MCSE

La Méthodologie de Conception des Systèmes Électroniques (MCSE) est développée par l'École Polytechnique Universitaire de Nantes. Son objectif est la conception conjointe matériel/logiciel pour des systèmes de contrôle/commande et les systèmes de communication. MCSE est une démarche complète qui permet de passer du problème à sa réalisation. MCSE est également le logiciel associé pour le développement et la conduite de projet.

<figure><img src="image_34.png" /><figcaption>FIG. 2.10 – Méthodologie MCSE.</figcaption></figure>

Le point d'entrée de cette méthodologie (Fig. 2.10) réside dans une description hiérarchique et graphique du système à créer. Ensuite, une succession d'étapes permet une progression du niveau le plus abstrait, décrivant l'application, jusqu'à sa réalisation opérationnelle représentant la solution finale comme un ensemble de cartes et de logiciels. Chaque étape permet d'enrichir la description par ajout d'informations à partir des contraintes à satisfiedre. Les erreurs peuvent être détectée et corrigées à chaque étape, avant de pouvoir passer à la suivante. MCSE propose aussi la construction d'une documentation au fur et à mesure du développement, inscrivant les démarches et choix qui ont abouti au produit final, et facilite ainsi la reprise d'un projet par une tierce personne.

Le travail de CoDesign, c'est-à-dire la conception d'un système mêlant composants dédiés et processeurs, est pris en compte. A partir des contraintes de temps et matérielles et de la description fonctionnelle de l'application, l'utilisateur est guidé dans les phases de partitionnement matériel/logiciel. Il peut en particulier évaluer les performances de plusieurs implantations possibles et choisir la meilleure.

Ensuite, le concepteur décrit le schéma d'interconnexion du matériel avec le logiciel, puis les programmes à implanter sur chacune des parties (en VHDL pour la partie
matérielle, en C pour la partie logicielle, en utilisant ou non un exécutif temps réel).

La méthodologie MCSE fournit une aide précieuse pour la conduite de projet: elle permet d'opérer de nombreux tests au fur et à mesure du développement, évitant de propager des erreurs en début de projet, ce qui pourrait être catastrophique au moment de la réalisation finale. L'outil MCSE fournit la description de systèmes de communication directement utilisable pour la synthèse du système. Par contre, l'utilisateur doit réaliser manuellement l'ordonnancement des tâches et leur positionnement sur les unités de calcul disponibles.

Comme toute méthodologie, l'utilisation de l'outil MCSE permet de restreindre le nombre de logiciels utilisés au cours des différentes phases de développement. Pour visualiser ce gain, le tableau 2.2 montre les fonctionnalités de divers outils, par rapport à celles de MCSE qui vont de l'établissement du cahier des charges jusqu'à la phase de prototypage. Il n'est alors pas nécessaire d'investir dans de nombreux logiciels, ni de former des spécialistes pour chacun d'eux.

<table><caption>TAB. 2.2 – Quelques outils et leur utilisation dans les phases méthodologiques.</caption><thead><tr><th>Outils</th><th>Cahier des charges</th><th>Specifications</th><th>Description fonctionnelle</th><th>Conception de l'architecture</th><th>Prototypage</th></tr></thead><tbody><tr><td>DOORS</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Requête Pro</td><td></td><td></td><td>Travail</td><td></td><td></td></tr><tr><td>RTM</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>CORE</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>RDD100</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>AREXSYS</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>CoWare</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Foresight</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Statemate Magman</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>COSSAP</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>SPW</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>STP</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>MATRIX</td><td></td><td></td><td></td><td></td><td>Logiciel</td></tr><tr><td>System architect</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>MathWorks</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>COSMOS</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>SES-Workbench</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Behav C, Monet, Renoir</td><td></td><td></td><td></td><td></td><td>Matériel</td></tr><tr><td>Apex</td><td></td><td></td><td></td><td></td><td>Logiciel</td></tr><tr><td>Seamless</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>Eagle</td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>EDS & VHDL-ICE</td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table>

Dans le cas d'une implantation multi-processeurs, l'intérêt de MCSE réside dans la description des applications constituées de plusieurs opérateurs concurrents (multi-tâches), interconnectés avec des systèmes de type boîte-à-lettre, sémaphore ou interruption. L'utilisation d'un RTOS est particulièrement adaptée à ce type de projets (Part 2.2.2).
### 2.3.2 Pegasus

Un autre exemple de logiciel basé sur une description avec des graphes flot de données est Pegasus. Ce logiciel de développement permet de créer des blocs logiciels et matériels et de les interconnecter dans un même graphe (Fig. 2.11). Les blocs matériels représentent un type de composant (C40, C60, Sharc ou Trimedia) que l'on peut relier entre eux par des liens physiques.

<figure><img src="image_35.png" /><figcaption>FIG. 2.11 – *Environnement de Développement Pegasus.*</figcaption></figure>

L'utilisateur définit un bloc pour chaque tâche à effectuer et connecte ces blocs logiciels sur les blocs matériels représentant la plate-forme. Pegasus fournit une trame en C standard à compléter pour réaliser un bloc logiciel désiré. Les blocs logiciels peuvent être stockés dans des bibliothèques pour de futures réutilisations. A partir de ces descriptions, Pegasus crée le code à implanter sur chaque DSP en se servant de l'OS temps réel Diamond 3L. Il est donc possible de programmer des plateformes à base de C40, de C60, de sharc ou de TriMedia.

Pegasus est un outil pratique pour implanter une application mono-DSP sur plate-forme multi-DSP. Son principal avantage est son environnement de développement à base de blocs, simple d'utilisation et qui permet au développeur de s'affranchir des problèmes matériels comme la synchronisation des DSP, ou la gestion des transferts des données. Ce-pendant, il reste destiné aux plateformes constituées de plusieurs composants identiques, et crée un code automatiquement pour un RTOS spécifique. Les possibilités d'évolution sont restreintes, spécialement au niveau de l'implantation sur des architectures plus complexes mettant en œuvre des FPGA. De plus, Pegasus ne règle pas le problème du positionnement manuel des calculs sur les différents DSP.

### 2.3.3 AVS/SynDEx

Nous décrivons ici la méthodologie AVS/SynDEx utilisée pour l'implantation d'algorithmes sur architectures parallèles homogènes, constituées de processeurs usuels (DSP),
ou sur architectures mixtes constituées de DSP et de FPGA (Fig.2.19). La création d'AVS/SynDEx dans notre laboratoire à débuté en 1996 et a été développé par Virginie Fresse de 1997 à 2001 [Fre01, FAD99]. Les applications recherchées se focalisaient sur des chaînes complètes de traitement d'images, le partitionnement sur les différentes unités de calcul étant automatique.

La spécialité requise pour l'utilisateur d'un tel processus de portage d'images concerne uniquement celle du traiteur d'images. Tous les autres concepteurs nécessaires dans la méthodologie de conception ne sont plus nécessaires, dans la mesure où les modules matériels sont déjà disponibles. Les outils mis en jeu sont relativement simple à manipuler, accélérant de ce fait le processus d'implantation. Quant à l'aspect vérification fonctionnelle et simulation de la description, ceci est effectué dès le début de la conception, à travers l'outil de développement propre au traiteur d'images. Il en résulte qu'aucune erreur au niveau algorithmique ne peut apparaître lors du prototypage.

AVS/SynDEx est basé sur l'utilisation de deux logiciels: AVS et SynDEx qui vont être présentés dans un premier temps. La particularité de cette méthodologie est la création quasi-automatique d'exécutifs distribués statiques performants pour architectures homogènes, mais également hétérogènes en conservant l'utilisation des environnements.

### 2.3.3.1 AVS

AVS, Advanced Visual System, est un outil de haut niveau de visualisation de données permettant le développement d'applications. Ces dernières sont principalement destinées aux créations graphiques. AVS est constitué d'un environnement de programmation visuel, d'un large ensemble de fonctions graphiques et de visualisation, ainsi que d'un ensemble d'outils permettant de développer des applications complexes graphiques de manière plus aisée. Il propose des modèles d'applications et d'outils de développement pour les environnements UNIX, Windows NT, 2000 et XP, Java et C++.

AVS se sert de méthodes avancées de visualisation de données, telles que les couleurs, le mouvement, la forme et la taille pour des indications précises concernant les données. Cet outil s'avère relativement performant pour un large éventail de domaines. Par exemple, il est fréquemment utilisé en imagerie biomédicale pour des visualisations obtenues au moyen de techniques 2D et 3D (l'objectif principal dans ce type d'application est la fusion d'images obtenues avec différentes sources et la visualisation des résultats).

AVS est également utilisé pour des applications d'ingénierie des structures: il est parfaitement adapté pour l'analyse du comportement des fluides, la compréhension et les prédictions de leur comportement par simulation. Il peut être intégré dans des domaines très différents allant du traitement de la nourriture ou de l'eau jusqu'à l'aérospatiale en passant par l'aérodynamique automobile et la conception de turbines à gaz. Le "National Weather Service" américain a développé une application de visualisation de prévisions météorologiques avec l'aide d'AVS (Fig. 2.12).

On peut de même citer les domaines des télécommunications, le traitement d'images, ainsi que l'analyse financière, avec par exemple l'exploitation d'ensembles de données massives dans le cas de recherches d'une anomalie suggérant des activités illégales dans le système bancaire. De plus, il peut aisément s'interfacer avec d'autres outils, un exemple illustrant bien ceci a été fait par une banque italienne, l'AIS de Milan, (Artificial Intelligence Software), qui interface AVS avec Oracle DBMS.
<figure><img src="image_36.png" /><figcaption>FIG. 2.12 – Application de prévisions météorologiques développée avec AVS.</figcaption></figure>

Présentation d'AVS

Un environnement de programmation visuel appelé Network Editor (NE) consiste en plusieurs bibliothèques de modules ainsi qu'en un espace de travail dans lequel les applications sont construites (Fig 2.13).

<figure><img src="image_37.png" /><figcaption>FIG. 2.13 – Environnement de développement AVS.</figcaption></figure>

Ces applications sont créées en ouvrant des "instances" de classes d'objets et en les connectant ensemble dans un réseau. Ces objets sont soit choisis parmi des objets déjà existants en bibliothèques, soit construits directement par l'utilisateur. Dans ce dernier cas, l'outil se charge de réaliser l'interfaçage d'entrée/sortie, alors que l'utilisateur doit lui écrire le code fonctionnel de l'objet (en C, C++ ou fortran).
AVS contient les éléments suivants :

- environnement de programmation visuel,

- interface utilisateur graphique (GUI),

- ensemble de fonctions de visualisation,

- ensemble graphique,

- interface de base de données,

- ensemble de graphisme et de connexions,

- outils de développement.

L'outil de visualisation AVS/Express offre un outil d'importation de données qui facilite
le processus d'échange des données utilisateur dans l'environnement AVS/Express.

Développement d'un module

AVS/Express contient des outils de développement logiciels tels que l'outil Add Mo-
dule, permettant à l'utilisateur de décrire des modules logiciels. C'est une série de menus
contenant des fenêtres de dialogues qui guident l'utilisateur à travers les différentes étapes
de description d'un nouveau module (Fig 2.14). Après l'avoir nommé, il faut associer le
nouveau module à une fonction appelée "method" qui décrira son comportement en C,
C++ ou fortran.

<figure><img src="image_38.png" /><figcaption>FIG. 2.14 – *Définition d’un nouveau module sous AVS.*</figcaption></figure>

Par de simples "clics de souris", on peut alors définir les entrées/sorties du module,
leurs types, puis leur donner des propriétés :

- l'entrée peut déclencher ou non l'activation de sa fonction associée,

- on peut définir si une entrée doit être connectée obligatoirement ou non pour que le module s'exécute,

- les entrées/sorties peuvent être des variables ou des constantes, des tableaux contraints ou non contraints,

- on peut également définir des propriétés graphiques (couleur des ports par exemple).
Ensuite, grâce à ces informations, AVS génèrera un squelette de code source dans le langage spécifié pour ce module. Ce squelette comportera des fonctions spécifiques qui vont permettre de récupérer les entrées dans la fonction avec les propriétés choisies, et de mettre les sorties à jour à la fin de l'exécution. L'utilisateur devra écrire le comportement de son nouveau module puis le ranger dans une bibliothèque de son choix.

La compilation est faite directement sous AVS qui utilise Visual C++, de manière transparente pour l'utilisateur.

AVS est orienté objet : les entrées/sorties et la méthode sont des sous-objets d'un module. Il est aussi possible de créer une hiérarchie entre modules, et d'utiliser l'héritage de méthodes qui en découle.

### Développement d'une application

On peut éditer des objets et établir des connexions sans afficher visuellement les informations. Ces connexions indiquent les relations entre objets : ainsi, un changement de valeur d'un objet engendre la mise à jour automatique des objets se référant à celui-ci.

#### 2.3.3.2 SynDEx

SynDEx [LS, GLS99, Gra00], dont la signification est "Synchronized Distributed Executive". SynDEx est un logiciel de CAO niveau système, fondé sur la méthodologie adéquation algorithme-architecture (AAA, [LS]), pour le prototypage rapide et pour l'optimisation d'applications distribuées temps- réel embarqué. Il a été conçu et développé à l'INRIA dans le projet OSTRE. C'est un produit académique qui peut être chargé gratuitement sur le web.

SynDEx est un environnement de développement graphique interactif conçu pour générer des exécutifs temps réel optimisés pour des programmes d'application spécifiés, soit avec le langage SIGNAL, soit directement en décrivant les graphes [LSSS91] [Nou01].

La version actuelle de SynDEx est la version 6, disponible depuis l'été 2002. Toutefois, au début de notre étude, la version disponible était la version 5. Cette dernière ne supportait pas les TMS320C4x, famille de processeurs que nous utilisons, les développements ont été réalisés sur la version 4.3.

<figure><img src="image_39.png" /><figcaption>FIG. 2.15 – Graphe d’algorithme de SynDEx V6.</figcaption></figure>

SynDEx nécessite la description de deux graphes. D'une part, un graphe d'algorithme (Fig. 2.15) permet de spécifier l'application à prototyper sous la forme d'un graphe flot de données, en faisant ressortir son parallélisme potentiel. Les sommets du graphe caractérisent une action ("operation"), une entrée/sortie ("Sensor" ou "Actuator"), une
mémorisation ("Memory"), une constante ("Constant") ou une mémorisation de données ("Memory"). Ces sommets sont reliés par des arcs qui représentent un transfert de données entre sommets. Cet algorithme peut être interfacé avec des langages synchrones de type SIGNAL.

D'autre part, un graphe d'architecture qui implique les organes de calculs (processeurs ou composants spécialisés) et les média de communication les reliant (Fig. 2.16), définit le parallélisme disponible de l'architecture sur laquelle on veut implanter l'application.

<figure><img src="image_40.png" /><figcaption>FIG. 2.16 – Graphe d'architecture de SynDEx V6.</figcaption></figure>

Une fois ces deux graphes réalisés, SynDEx effectue le placement-ordonnancement de l'algorithme sur l'architecture. Le placement-ordonnancement correspond à deux étapes précalculées et statiques. Le principe consiste à affecter et séquentialiser les processus de calcul (respectivement d'entrée/sortie) sur les différents processeurs (respectivement d'entrée/sortie). Ces tâches sont réalisées simultanément par un algorithme basé sur une heuristique qui vise à minimiser le temps de réponse de l'application, obtenu par simulation du comportement temps réel de l'application et de la machine cible. L'heuristique utilisée ne consiste pas à tester l'ensemble des configurations possibles de l'algorithme sur une architecture, et à conserver la plus rapide : ces calculs seraient alors extrêmement longs. En revanche, l'heuristique consiste à faire progresser le long du graphe logiciel une coupe séparant les processus déjà placés sur des processeurs, de ceux qui ne le sont pas encore, et pour chaque processus, évaluer le coût du placement et de l'ordonnancement à l'aide d'une fonction prenant en compte les communications. Cette technique permet de limiter l'exploration aux possibilités susceptibles d'apporter les meilleures performances. Ce placement produit des communications inter-processeur qu'il faut également placer et ordonnancer sur les processeurs de communication.

Cette étape de placement-ordonnancement comporte deux phases : la première consiste en une exécution séquentielle du graphe sur un seul processeur. De cette exécution sont ainsi déterminés les temps de traitement de chaque bloc de l'algorithme sur ce processeur. Si la plate-forme est hétérogène, l'utilisateur doit réaliser cette tâche de chronométrage sur chaque type de composant de la plate-forme. Les temps sont ensuite reportés manuellement sous SynDEx et les tâches de placement-ordonnancement peuvent être effectuées. Le traiteur d'images a la possibilité de contraindre tout le processus à être placé sur un processeur particulier. Ces contraintes peuvent correspondre à des nécessités matérielles, telles que l'obligation pour les processus d'entrée/sortie du système à être situés sur un processeur précis du graphe d'architecture. Il faut également définir la durée des communications inter-processeur.
La visualisation du résultat s'effectue grâce au graphe temporel fourni par SynDex: le *"time schedule"* (Fig. 2.17). Ce diagramme met verticalement (dans la version 6, il est possible de visualiser le résultat horizontalement) en évidence la répartition des tâches sur les différents processeurs et les éventuelles parallélisations, ainsi que les transferts de données entre ceux-ci. SynDEx indique également l'accélération obtenue. Chaque colonne représente les tâches effectuées sur un processeur, ou une communication sur un média, et ceci en fonction du temps (le début du graphe étant situé tout en haut). Cette prédiction permet de visualiser le parallélisme obtenu et, si nécessaire, d'optimiser l'implantation. Pour cela, l'utilisateur peut interagir avec l'heuristique pour l'aider à trouver de meilleurs résultats, en adaptant la taille des grains de l'algorithme, en modifiant les ressources de l'architecture ou en ajoutant des contraintes de placement de certains sommets du graphe d'algorithme.

<figure><img src="image_41.png" /><figcaption>FIG. 2.17 – Adéquation SynDEx V6.</figcaption></figure>

Après la construction du graphe d'implantation, SynDEx génère un macro-code indépendant des langages utilisés par les processeurs (Fig. 2.18). 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 code, constituant les programmes de chaque processeur, en un exécutif compilable [GLS99]. Il est nécessaire pour cela de disposer de bibliothèques de traduction fournies avec SynDEx.

L'utilisateur n'a pas d'autre code à écrire que celui des processus de calcul et d'entrée/sortie. Tout le reste, ordonnancement, et appel des processus de calcul et d'entrée/sortie, al-
location de la mémoire nécessaire aux communications inter-processus, intra et inter-
processeurs et code des processus de communication, est généré automatiquement par
SynDEx à partir des graphes logiciels et matériels, des résultats de placement ordonnан-
cement et du noyau générique de l'exécutif SynDEx.

<figure><img src="image_42.png" /><figcaption>FIG. 2.18 – *Utilisation de SynDEx*</figcaption></figure>

Le principal avantage de SynDEx est d'éviter les OS temps réels. SynDEx permet de générer un exécutif **statique, taillé sur mesure** pour une application donnée, en évitant le surcoût spatial et temporel par rapport à l'implantation d'un OS résidant. L'exécutif garantit l'ordre partiel du graphe d'algorithmme fixé et visualisé sur le diagramme temporel, **évitant tout inter-blocage**, exercice complexe lors de développements manuels.

La génération de code de SynDEx est basée sur un macro-code indépendant des pro-
cesseurs sur lesquels sont implantés les programmes. Le macro-processeur standard des
systèmes Unix M4 permet de générer automatiquement les exécutifs pour les cibles dont
les bibliothèques M4 ont été développées, pour les processeurs et les médias de communi-
cation suivant :

Processeurs :

- Analog Device ADSP 21060 - SHARC

- Texas TMS320C40

- Motorola MPC 555 et MC 68332

- Intel i80x86 et i8096

- stations de travail sous Unix/Linux

- RTAI-Linux

Médias de communications :

- Communication par TCP/IP

- Bus CAN

- Liens point-à-point C40

- SHARC

SynDEx est un outil en constante évolution. SynDEx version 6 offre de nouvelles fonctionnalités comme la possibilité de définir une hiérarchie, un conditionnement et des répétitions dans le graphe d'algorithmme. Dans le graphe d'architecture, plusieurs types de médias sont maintenant autorisés: RAM, SAM point à point ou encore SAM multi-points. Les noyaux d'exécutifs fournis ne supportent pas encore ces nouvelles fonctionnalités.
### 2.3.3.3 Méthodologie AVS/SynDEx multi-processeurs

Nous avons défini une plate-forme logicielle (Fig. 2.19) intégrant AVS et SynDEx.

Le point d'entrée de notre plate-forme consiste en une description fonctionnelle de notre application par l'intermédiaire de l'environnement AVS. Cet environnement de développement d'applications permet à l'utilisateur de concevoir son graphe flot de données. Il a la possibilité d'utiliser des modules déjà définis et rangés dans des bibliothèques ou bien de créer lui même ses modules en développant ses fonctions C associées, qui seront compilées puis rangées dans des bibliothèques utilisateur. En sortie d'AVS, l'utilisateur a conçu puis vérifié fonctionnellement son application. Les étapes de modifications de la fonctionnalité de l'application ou d'éventuelles optimisations de code sont entièrement réalisées à ce niveau.

<figure><img src="image_43.png" /><figcaption>FIG. 2.19 – Méthodologie AVS/SynDEx.</figcaption></figure>
Ensuite, un traducteur développé dans notre laboratoire transforme le graphe flot de données d'AVS et en génère un nouveau parfaitement compatible (et donc directement utilisable) avec l'environnement SynDEx. Celui-ci récupère toutes les informations nécessaires pour une utilisation sous SynDEx, notamment la structure générale du graphe, (soit tous les noms des modules utilisés et la fonction correspondante, et les interconnexions entre ceux-ci) et les paramètres des modules utilisés (le nom et la taille des entrées et sorties).

Il est bien sûr indispensable d'imposer certaines contraintes sur la description sous AVS pour qu'elle puisse être portée automatiquement sur la plate-forme matérielle. Tout d'abord, le traducteur donne une description du graphe d'algorithme pour la version 4.3 de SynDEx. Une conséquence directe en est que l'application doit posséder un point d'entrée (IN) et un seul point de sortie (OUT). Ensuite, les modules utilisés dans la description ne peuvent être que des modules utilisateur. Cette contrainte est évidente par le fait qu'il faut connaître le code associé à chaque module. Cela suppose en outre que l'application ne doit pas contenir de modules AVS prédéfinis tels que ceux destinés à la création des interfaces graphiques. En pratique, cela revient à éventuellement utiliser 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 à revenir à une description minimale pour le portage.

Les entrées et les sorties des modules doivent être des tableaux de taille contrainte, autrement dit dont la taille est spécifiée lors de la définition du module. Cette restriction imposée par SynDEx s'explique par l'allocation statique réalisée dans la génération de code. Sous AVS, il est possible de ne pas indiquer explicitement la taille d'un tableau, qui est alors obtenue dynamiquement lors de l'exécution de la fonction associée et qui correspond à celle du lien connecté au module. Cette possibilité ne devra pas être utilisée pour la version utilisée par le traducteur.

Le graphe d'algorithme étant décrit sous l'environnement SynDEx, l'utilisateur doit réaliser une implantation mono-processeur afin de connaître les temps d'exécution des opérations de calcul sur chaque élément de la plate-forme multi-composants. Dans le cas d'une architecture homogène, une seule implantation mono-processeur est nécessaire. L'utilisateur génère l'adéquation, puis la génération automatique de code avec les options de chronométrage. L'exécution du code généré se réalise avec l'outil spécifique au composant (GODSP pour les TMS320C4x). Les temps chronométrés sont reportés par l'utilisateur dans le graphe d'algorithme sous SynDEx, qui peut alors générer une adéquation optimale de l'algorithme et fournir l'ordonnancement spatial et temporel des calculs. L'exécutif distribué statique est alors chargé sur l'architecture multi-DSP.

L'avantage de notre processus est, outre l'intervention d'un traiteur d'images dont le travail est de créer son application sous l'environnement AVS, que sa seule intervention apparaisse pour la détermination des temps de traitement de chaque étape de calcul.

Notre méthodologie est relativement ouverte. En effet, d'autres outils permettant l'élaboration de graphes flot de données peuvent se substituer à AVS. Une étude [FD02, FBD00] réalisée avec Ptolemy a abouti à la création d'un traducteur Ptolemy/SynDEx. Ptolemy est un logiciel utilisé par de nombreux concepteurs de traitement du signal et des images. C'est un outil universitaire développé par l'université de Berkeley et disponible gratuitement, ce qui autorise une meilleure diffusion dans le domaine universitaire, mais
aussi industriel.

D'autre part, on pourrait également envisager l'utilisation d'un logiciel tel que COS-SAP pour développer des applications de communications numériques que l'on voudrait porter sur architectures parallèles. Finalement, tout logiciel permettant la description, simulation et débogage de graphe flots de données peut être interfacé à SynDEx pour la vérification fonctionnelle d'applications.

### 2.3.3.4 Méthodologie AVS/SynDEx et CoDesign

SynDEx a été étendu pour pouvoir procéder à des implantations sur des composants FPGA: la méthodologie AAA est étendue dans le cas des multi-FPGA, toujours dans le domaine du traitement des images temps réel [DLAS98, DALS00]. Il s'agit de mettre en place les principes permettant de synthétiser le circuit correspondant à une spécification algorithmique faite à l'aide d'un modèle de graphe de dépendances factorisé. Ce dernier est transformé, en suivant les règles de synthèse basée sur le modèle RTL et des mécanismes de transferts de données synchronisés, en un graphe matériel comprenant les chemins de données et de contrôle. Ces règles serviront par la suite pour réaliser automatiquement la synthèse de circuits. Cependant, la génération de code pour parties dédiées n'est pas encore mise en œuvre.

[Fre01] a utilisé SynDEx sur une plate-forme mixte, dans le cas particulier où le FPGA de la plate-forme de test était vu par les autres DSP disponibles comme un DSP. Les communications pouvaient alors être traitées comme dans le cas d'architectures homogènes multi-C4x [FDA00]. Les fonctions C décrivant les fonctionnalités de l'algorithme sous AVS étaient remplacées par des cores équivalents lors de l'implantation. Dans le cas où ces cores sont disponibles, tous les aspects matériels nécessaires pour l'implantation sur FPGA sont masqués.

Une étude est actuellement lancée dans le laboratoire IETR, Groupe Systèmes Télécommunication Radar, sur la génération automatique de code VHDL à partir de SynDEx, dans l'objectif de paralléliser des fonctions au sein d'une architecture hétérogène [Her02]. Actuellement, la génération automatique de VHDL n'est pas encore finalisée, mais une architecture interne du FPGA permettant l'implantation automatique de séquences de calculs ainsi que leurs synchronisations a été mise au point. Le concepteur décide du nombre de processeurs qu'il désire implanter dans son FPGA afin d'optimiser le parallélisme dans le composant.

<figure><img src="image_44.png" /><figcaption>FIG. 2.20 – Représentation de l'architecture du FPGA sous SynDEx</figcaption></figure>
Au niveau du graphe d'architecture utilisé pour l'adéquation, le FPGA est modélisé comme un processeur (routeur) qui rend possible la liaison entre l'architecture logicielle (un DSP disponible sur la plate-forme test) et l'architecture matérielle. La figure 2.20 montre une architecture divisée en deux unités de calcul P2 et P3, mais le concepteur peut, en fonction de l'algorithme à implanter et de la place qu'il possède sur son FPGA implanter d'autres unités de calcul. Chacun des processeurs possède une architecture (Fig. 2.21) permettant de communiquer avec les autres processeurs du FPGA et le routeur, des espaces mémoires pour sauvegarder les données nécessaires aux calculs, des blocs calculs qui correspondent aux noeuds du graphe d'algorithme de SynDEx, exécutés ultérieurement par ce processeur, ainsi qu'un système de synchronisation afin d'exécuter les calculs dans l'ordre indiqué par l'adéquation.

<figure><img src="image_45.png" /><figcaption>FIG. 2.21 – Architecture générique d'un processeur</figcaption></figure>

La génération du code VHDL automatique à partir du macro-code générique fourni par SynDEx est en développement et permettra l'utilisation de SynDEx sur des plate-formes mixtes. La prise en compte d'architectures mixtes dans AVS/SynDEx ayant été étudiée, la génération de code VHDL dans notre méthodologie sera rapide [FDN02].

## 2.4 Synthèse

Ce chapitre nous a permis de présenter les architectures matérielles actuellement utilisées. Dans un premier temps, nous avons rappelé les différences entre les grands types de composants usuels comme les processeurs, les DSP et les circuits spécialisés. La tendance actuelle est clairement à une fusion entre ces différentes familles de composants, si bien qu'il sera de plus en plus facile de créer des architectures complexes constituées de plusieurs unités de calculs. De telles architectures restent cependant complexes à programmer, entraînant des temps de développement longs, bien souvent couplés à une sous-utilisation des ressources de l'architecture.

La seconde partie de ce chapitre a été l'occasion de rappeler les différentes opérations
nécessaires à la programmation d'architectures parallèles dans le cas du temps réel embarqué. Les RTOS disponibles sur le marché sont une aide précieuse puisqu'ils permettent de mettre en oeuvre facilement tâches, synchronisations, et partages des données, tout en contrôlant l'ordonnancement des calculs. Dans le cas d'architectures multi-composants, les communications sont facilitées.

Les RTOS commerciaux sont basés sur des processus dynamiques, et sont résidents. De ce fait, ils limitent les performances temps réel embarqué. Bien que moins généralistes, des systèmes temps réel taillés sur mesure, et basés sur des processus statiques permettent d'optimiser les performances indispensables pour ce domaine. De plus, l'utilisation de ces produits commerciaux doit être couplée à d'autres outils de manière à mener un projet du cahier des charges jusqu'au prototypage matériel et/ou logiciel. La complexité d'un développement est accrue puisqu'il nécessite une expertise plus importante. De plus, l'enchâinement entre les différents outils doit être organisé, ce qui devient complexe lorsque des erreurs doivent être corrigées. Une approche globale du développement (méthodologie de conception) basée sur un ensemble d'outils sans rupture permet d'apporter une sécurité de conception qui aboutit forcément à des gains de temps lors d'un développement, ainsi qu'à des réutilisations pour de futurs développements.

Enfin, nous avons présenté trois méthodologies de développement que sont MCSE, Pegasus et AVS/SYNDEX. L'utilisation d'une méthodologie complète apporte des gains de temps considérables sur le temps global de développement. Alors que la plupart des méthodologies, comme MCSE et Pegasus, se basent sur l'utilisation de RTOS résidents pour l'implantation finale, AVS/SynDEX propose une implantation statique et taillée sur mesure des algorithmes sur la plate-forme.

Le développement des applications par AVS permet de réaliser une description, sa vérification fonctionnelle et son optimisation, à un **haut-niveau d'abstraction**. Cette interface permet de construire des **graphes flot de données** particulièrement adaptés à la description d'applications ayant une forte notion de précédence, comme c'est le cas en codage et décodage vidéo. L'utilisateur peut être alors être **seulement un traiteur d'images** ne connaissant pas les mécanismes de communication et de séquencement utilisés pour l'implantation multi-processeurs. Les opérations de **partitionnement et d'ordonnancement** sont réalisées **automatiquement** par SynDEX. L'exécutif optimisé pour chacune des unités de calculs de l'architecture est créé automatiquement par SynDEX, suivant la répartition et l'ordonnancement généré, et évitant les inter-blocage difficile à prévoir lors d'une réalisation manuelle. L'exécutif est de plus taillé sur mesure pour une optimisation des ressources embarquées sur les processeurs. L'utilisation du compilateur et des bibliothèques disponibles pour le DSP cible doit être maîtrisée pour des performances accrues.

MCSE est une méthodologie complète, associée d'un logiciel pour le mise en oeuvre de toutes les phases méthodologiques. Cependant, l'ensemble des étapes (placement, ordonnancement, gestion des communications et synchronisations) doivent être réalisées **manuellement**. Étant donné le nombre des étapes à réaliser, la maîtrise et l'optimisation de toutes les phases reste complexe et nécessite plusieurs experts. L'utilisation
d'une méthodologie comme MCSE sera certainement mieux adaptée à des implantations
de parties systèmes Mpeg, car celles-ci doivent être constamment adaptées aux évolutions
du (des) réseau(x), ainsi qu'aux actions de l'utilisateur. Des mécanismes fortement dyna-
miques devront alors être mis en œuvre.

Contrairement à la méthodologie MCSE, où l'architecture est conçue en même temps
que l'application, AVS/SynDEx permet de créer d'abord une application, et ensuite de
réaliser son prototypage de manière automatique sur une plate-forme cible. L'utilisateur
peut alors simuler le comportement de son application sur des architectures, en sa pos-
session ou avant achat, et ainsi adapter le nombre d'unités de calcul nécessaires à son
application.

En conséquence, la méthodologie AVS/SynDEx présente de nombreux avantages tant
au niveau de la simplicité d'utilisation que des performances finales. Notre objectif cible
donc une utilisation d'AVS/SynDEx sur des applications complexes de traitement vidéo
afin de valider la méthodologie. Les applications Mpeg restent un défi pour des implanta-
tions sur multi-DSP. En se situant dans un contexte temps réel embarqué où chaque unité
de calcul doit être utilisée à son maximum pour améliorer le rapport puissance de cal-
cul/consommation, des résultats d'implantations automatiques sur de telles applications
montreront l'efficacité d'AVS/SynDEx.
# Chapitre 3

## Descriptions et intégrations d'applications Mpeg

Au début de ce travail de thèse, la méthodologie AVS/SynDEx avait été uniquement testée sur des algorithmes de traitement d'images fixes, qui ne nécessitaient pas de grosses ressources et qui étaient relativement simples, notamment sans conditionnement. Les implantations réalisées étaient portées automatiques sur des plate-formes multi-C4x [Fre01]. Le temps de portage d'un algorithme dans ces conditions et une fois la description réalisée sous AVS, était d'une vingtaine de minutes.

Par ailleurs, le standard Mpeg-4 apparaissait à la même époque dans ses premières versions (première version figée fin 1998). Ses premières implantations logicielles étaient en cours de développement. Si actuellement des logiciels de décodage en temps réel existent, il n'en va pas de même pour des codeurs temps réels. D'autre part, les algorithmes Mpeg sur DSP restent peu développés, et limités à certaines opérations comme les DCT ou VLC Inverse Mpeg-2. La première implantation totalement intégrée à un DSP a vu le jour en 2001 [Ele01a]. Son intégration a été réalisée par la société Ateme, spécialisée dans les solutions logicielles pour DSP, et concerne seulement un décodeur. L'intégration d'un codeur apparaît plus complexe et reste non proposée pour DSP. En revanche, de nombreux produits dédiés sont disponibles pour les codages et décodages Mpeg-2. Il s'agit souvent de cartes spécialisées, constituées de parties logicielles et de parties dédiées particulièrement lourdes à développer.

Mes travaux ont eu pour but de développer la méthodologie AVS/SynDEx pour pouvoir réaliser le prototypage d'applications complexes, et plus particulièrement Mpeg-4, sur architectures multi-DSP. Dans un premier temps, les plate-formes de réalisation de ce travail feront l'objet d'un paragraphe. L'utilisation de la génération automatique de code pour une plate-forme multi-C6x à l'aide de SynDEx est aujourd'hui possible grâce au développement du noyau d'exécutif adapté présenté dans le paragraphe suivant. Enfin, ce chapitre se terminera avec la présentation des différentes applications testées sur la plate-forme multi-C6x : un codeur LAR, un codeur Mpeg-2 puis d'un décodeur Mpeg-4.