CONCEPTION ET IMPLÉMENTATION DU

SYSTÈME MULTIMÉDIA EMBARQUÉ

ECOLE NATIONALE DES SCIENCES APPLIQUEED DE KHOURIBGA

2émé Année cycle ingénieur : Génie Electrique
Encadré par :Mr. Ismail Laghrat

Siham Darif Rabiaa Manar Sliman Ennayri Omar Barmaki

Yacine a.Amkassou
Remerciements

Nous tenons à remercier dans un premier temps, toute l’équipe pédagogique de l’Ecole
Nationale des Sciences Appliquées de Khouribga , pour avoir assuré la partie théorique de notre
formation.
Nous remercions également M. Ismail Laghrat pour l’aide et les conseils qu’il nous a
apporté lors des différentes étapes de l’élaboration de notre projet. Nous tenons à vous remercier
du fond du cœur également pour chaque minute passée avec nous ; pour chaque information et
pour chaque nouvelle leçon que vous avez enseignée.
On sait bien que n’a pas été du facile de nous enseigner ; parfois dû à notre manque de base
d’autre fois à notre surcharge, merci de ne pas avoir baissé les bras quand même ; de nous avoir
tant soutenu et encourager pour arriver au bout, que Dieu vous bénisse.

1
Table des matières

1 LA CONCEPTION DES SYSTÈMES EMBARQUÉES NUMÉRIQUES 1

1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Méthodologies de Conception des systèmes numériques . . . . . . . . . . . . . . 1
1.2.1 Généralités . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2.2 Réalisation d’un système sur puce SoC ou SoPC . . . . . . . . . . . . . 3
1.2.3 Les différentes familles de blocs IP . . . . . . . . . . . . . . . . . . . . . 3
1.3 Les circuits à logique programmable . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Types d’architectures et éléments des circuits FPGA . . . . . . . . . . . 4
1.3.2 Exemple de circuit FPGA : la famille Altera cyclone II . . . . . . . . . . 4
1.4 Le processeur embarqué NIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1 Processeur NIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4.2 Bus Avalon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2 CONCEPTION DU SYSTÈME MULTIMÉDIA EMBARQUÉ 11

2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Plateforme matérielle de traitement vidéo . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Conception d’un système SoPC . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Platforme de développement : CycloneII FPGA Multimedia board . . . . . . . . 15
2.3.1 Caractéristique générale . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Système d’acquisition et de traitement vidéo . . . . . . . . . . . . . . . . . . . . 17
2.5 Principe de base de traitement d’image . . . . . . . . . . . . . . . . . . . . . . . 17
2.5.1 Définition d’une image et des types d’images . . . . . . . . . . . . . . . . 17
2.5.2 Changement d’espace de couleur . . . . . . . . . . . . . . . . . . . . . . . 18
2.5.3 Définition de la vidéo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 RÉALISATION DU SYSTÈME 20
3.1 Configuration de capteur CMOS . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 Notre Système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 création de système sur quartus II et SoPC builder . . . . . . . . . . . . . . . . 23
3.4 Le premier test : Hello World ! . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5 Programme de traitement d’image . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5.1 L’algorithme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5.2 les fonctions de altera avalon pio regs.h . . . . . . . . . . . . . . . . . . . 26
3.6 L’implémentation du programme . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Conclusion 28

2
Table des figures

1.1 Evolution de la conception numérique . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 SoC basé coeurs de processeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Niveau supérieur de la hiérarchie de l’architecture du circuit Stratix II . . . . . 5
1.4 Système Altera NIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 CPU NIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6 Instruction personnalisée du processeur NIOS II . . . . . . . . . . . . . . . . . . 7
1.7 Implantation du processeur NIOS II sur différents circuits FPGA d’Altera . . . 8
1.8 Bus Avalon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.9 Cycle de lecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.10 Cycle d’écriture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 Conception traditionnelle et codesign . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2 Quartus II 11.0 SP1 interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Flot de conception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 SOPC Builder et mapping mémoire . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5 CycloneII FPGA Multimedia board . . . . . . . . . . . . . . . . . . . . . . . . 15
2.6 CycloneII FPGA Multimédia board multimédia composantes . . . . . . . . . . 16
2.7 Notre système d’acquisition, traitement et restitution vidéo . . . . . . . . . . . 17
2.8 Elément d’une image : le pixel . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.9 Superposition des trois couleurs : rouge, vert et bleu . . . . . . . . . . . . . . . 18
2.10 Principe de balayage utilisé pour la vidéo et la télévision . . . . . . . . . . . . . 19

3.1 inputs/ouputs de capteur CMOS . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2 registres d’instructions de capteur CMOS . . . . . . . . . . . . . . . . . . . . . . 21
3.3 configuration du camera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 notre système NIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.5 vue d’ensemble de notre système NIOS . . . . . . . . . . . . . . . . . . . . . . . 23
3.6 le processeur NIOS et leurs périphériques . . . . . . . . . . . . . . . . . . . . . 24
3.7 le schéma block de notre système . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.8 Hello world . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3
 Résumé

Le sujet de ce projet est la contribution au développement et à la conception d’un système

multimédia embarqué en utilisant la méthodologie de conception conjointe logicielle/matérielle
(codesign). Il en a découlé la constitution d’une bibliothèque des modules IP (Intellectual Pro-
perty) pour les applications vidéo. Dans ce contexte, une plateforme matérielle d’acquisition
et de restitution vidéo a été réalisée servant de préalable à l’évaluation de la méthodologie de
conception en codesign et à toute étude d’algorithme de traitement vidéo. On s’est intéressé en
particulier à l’étude et à l’implantation de la . La fréquence de fonctionnement de la plateforme
est de 25 MHz. L’ensemble du développement est exécuté par le processeur NIOS II sous un
application développer a l aide de NIOS IDE .
Chapitre 1

LA CONCEPTION DES SYSTÈMES

EMBARQUÉES NUMÉRIQUES

1.1 Introduction
Les avancées actuelles dans la technologie des semi-conducteurs et des méthodologies de
conception permettent le développement de systèmes numériques complexes sur puce SoPC,
des dispositifs pouvant contenir des millions de transistors. Les derniers circuits FPGA (Field
Programmable Gate Array) permettent également le développement de systèmes complets.
Ainsi, un système qui était auparavant implanté sur une carte, peut dorénavant être conçu sur
une puce unique offrant l’avantage d’être compact et de supporter un très grand nombre de
traitements arithmétiques. La tendance actuelle est donc à l’assemblage dans une même puce
de plusieurs composants éventuellement hétérogènes pour répondre au mieux aux exigences
des systèmes multimédia embarqués. Ces composants peuvent être aussi bien des coeurs de
processeurs, des coeurs de DSP, des accélérateurs matériels... La réalisation de ces systèmes
a nécessité la mise en place d’une méthodologie de conception logicielle/matérielle (codesign)
prenant en compte les contraintes de l’embarqué.

1.2 Méthodologies de Conception des systèmes numériques

1.2.1 Généralités
Dans l’approche traditionnelle, un système numérique est un assemblage sur une carte de
différents composants discrets représentant chacun une fonction particulière plus ou moins
complexe telle qu’additionneur, mémoire, composant d’interface, gestionnaire d’interruption,
processeur... Si une erreur de conception était faite, il était au minimum nécessaire d’ajouter
des fils entre les composants, ou au pire, de refaire une carte pour régler le problème, c’est-
àdire reprendre complètement son routage. Plus le système numérique est complexe, plus ces
composants sont nombreux, plus la carte est chère, et plus les perturbations électromagnétiques
sont importantes. Un besoin existait donc de pouvoir modifier la logique sans modifier les cartes
et aussi de diminuer le nombre de composants sur une carte numérique. En effet, moins il y
a de composants remplissant un même cahier des charges, moins la carte est chère, et plus
les fonctions sont intégrées, plus il est possible de proposer une carte moins encombrante. Les
améliorations des processus de fabrication des composants électroniques ont permis de répondre
de mieux en mieux à ces besoins.
Dans ce contexte, l’International Technology Roadmap for Semiconductors affirme que les

1
processeurs contiennent en moyenne près de 100 millions de transistors en 2007 et en prévoit
près de 1.5 milliard pour 2013. L’évolution des technologies de fabrication de circuits permettent
l’intégration d’un système numérique sur un même composant : c’est le concept du single chip.
Ceci est en fait lié à la loi empirique de Moore qui stipule que pour une surface de silicium
donnée, on double le nombre de transistors intégrés tous les 18 mois . La loi de Moore a
radicalement changé la façon de concevoir les systèmes numériques aujourd’hui puisque l’on
peut procéder à l’implantation d’algorithmes complexes pour les systèmes numériques de futures
générations. On travaille maintenant au niveau système (ou fonctionnalité) et non au niveau
porte logique. Cette évolution de la conception peut être résumée sur la figure

Figure 1.1 – Evolution de la conception numérique

L’approche “schématique” au niveau portes logiques et fonctions de base RTL (Register

Transfer Logic) semble aujourd’hui délaissée pour la conception des systèmes complexes au
profit d’une approche “textuelle”. L’approche schématique reste cependant toujours valable et
est plutôt réservée à la conception des petits systèmes...
L’approche textuelle, on utilise des langages de description de matériel comme VHDL (Very
high speed integrated circuit Hardware Description Language) ou Verilog pour synthétiser une
fonction numérique. Ces langages de description de matériel sont en fait des langages de pro-
grammation qui sont utilisés conjointement avec un compilateur ou un simulateur. Ces langages
deviennent un standard et leur choix participe ainsi à la pérennité du produit. Il existe à l’heure
actuelle d’excellents synthétiseurs mixtes et multi-technologiques (par exemple Precision de
Mentor Graphics). Les fabricants de FPGA proposent maintenant leur propre synthétiseur.
Dans le développement des systèmes numériques complexes, il existe des besoins qui re-
viennent fréquemment. Certaines sociétés ont développé ou rassemblé des modules répondant
à ces besoins et les mettent sur le marché sous le nom de blocs IP (Intellectual Property)
(fonctions mathématiques : FFT, DCT, FIR, interfaces bus : PCI, RapidIO, coupleurs divers :
UART, HDLC. . . ). Ces modules IP peuvent être achetés ou téléchargés librement sur Internet.
On peut ainsi voir la conception d’un système numérique complexe comme un assemblage de
modules IP
Les langages de description de matériel sont aussi intéressants pour la facilité de modification
et de réutilisation d’un design précédent pour un nouveau design : c’est le design reuse.

2
1.2.2 Réalisation d’un système sur puce SoC ou SoPC
Un SoC est un ensemble de blocs fonctionnels intégrés dans un composant électronique avec
au moins un processeur comme élément de traitement. La figure représente un SoC qui est basé
sur des coeurs de processeurs. A partir de cette figure, on constate que seuls les L’approche

Figure 1.2 – SoC basé coeurs de processeurs

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 de SoPC pour System on Programmable Chip. Le
SoC peut être retenu pour les applications destinées au grand public. Il permet des meilleures
performances en termes de consommation, de vitesse et de surface. Mais, la fabrication et le
test sont des étapes longues et coûteuses . De plus, un SoC est figé et n’est donc pas réutilisable
pour une autre application. Par contre, le SoPC est un composant reconfigurable à volonté. Il
permet donc un développement et prototypage rapide du système. Mais, en contrepartie, on
peut avoir une consommation d’énergie plus grande avec une performance plus faible que celle
du SoC.

1.2.3 Les différentes familles de blocs IP

Un bloc ou un composant IP est un composant virtuel qui peut apparaı̂tre sous différentes
formes

IP Logiciel
softcore : le composant est livré sous sa forme HDL (Hardware Design Language) synthétisable,
c’est à dire flexible. Son principal avantage est sa portabilité. La propriété du fichier source est
en soi la meilleure documentation. On peut ainsi maintenir le produit pendant des années et
éventuellement modifier la source et même changer de technologie cible. L’inconvénient ma-
jeur est qu’il ne peut être prédictif en termes de superficie, puissance et temps. Le travail
d’optimisation du circuit final est à la charge de l’intégrateur du système.

IP Matériel
hardcore : Dans ce cas, le bloc IP est ciblé sur une technologie particulière et le travail d’opti-
misation est garanti. Cela englobe la netlist entière, le routage et l’optimisation pour une librai-
rie technologique spécifique, un layout personnalisé. L’inconvénient est qu’il est moins flexible
car le processus est dépendant de la technologie. Par contre il a l’avantage d’être prédictif.

3
IP Firm
firmcore : Le bloc IP firmcore offre un compromis entre le softcore et le hardcore, plus
flexible que le hardcore, plus prédictif en termes de performance et de surface que le softcore.
En général, le travail de synthèse HDL est déjà réalisé pour une technologie cible donnant lieu
à une description par netlist (format EDIF par exemple).

1.3 Les circuits à logique programmable

Actuellement, on trouve différentes familles de circuits programmables tels que les CPLDs
(Complex Logic Programmable Device) et les FPGAs. La différence entre ces deux types de
composants est structurelle. Les CPLDs sont des composants pour la plupart reprogrammables
électriquement ou à fusibles, peu chers et très rapides (fréquence de fonctionnement élevée) mais
avec une capacité fonctionnelle moindre que les FPGA. Par contre, ceux-ci sont des composants
VLSI constitués de blocs mémoires vives, entièrement reconfigurables. Ces blocs sont structurés
en LUT (Look Up Table), flip-flop, RAM et l’ensemble dispose d’un vaste système d’intercon-
nexions. Le progrès de la conception des circuits électroniques permet d’avoir des composants
toujours plus rapides et à plus haute densité d’intégration, ce qui permet de programmer des ap-
plications importantes comme par exemple les applications vidéo. À l’heure actuelle, on compte
une dizaine de fabricants, le marché étant nettement dominé par les sociétés Altera et Xilinx

1.3.1 Types d’architectures et éléments des circuits FPGA

Classiquement pour les architectures des circuits FPGA, on peut rencontrer trois topologies
différentes :

Architecture de type ı̂lots de calcul

Dès le départ, Xilinx a choisi ce type d’architecture. Cette architecture FPGA est constituée
d’une matrice plane d’éléments. Ces éléments constituent les ressources logiques et de routages
programmables du FPGA.

Architecture de type hiérarchique

Dans cette architecture, il existe plusieurs plans dans le FPGA. Mais, ces plans ne sont
pas physiques, ils correspondent aux niveaux de hiérarchie logique. C’est à dire qu’un élément
d’un niveau logique peut contenir des éléments de niveau logique inférieur, d’où la notion de
hiérarchie. Chaque niveau logique reprend la topologie d’une architecture du type ı̂lots de
calcul avec un routage dédié pour chaque niveau. Cette architecture se trouve dans les FPGAs
d’Altera.

1.3.2 Exemple de circuit FPGA : la famille Altera cyclone II

Altera a lancé au début de l’année 2004 un nouveau composant le Stratix II. Ce composant
est marqué par un certain nombre de changements par rapport aux architectures classiques
des premiers FPGA Altera (Flex et Apex) à trois niveaux de hiérarchie. Le circuit Stratix II
comme le circuit Stratix dont il a hérité de nombreuses caractéristiques, est moins hiérarchique
et n’a plus que deux niveaux de hiérarchie. Le niveau le plus haut (figure 27) consiste en un
ensemble d’éléments configurables LAB (Logic Array Bloc) qui sont répartis en matrice. A ce

4
même niveau, des mémoires de différentes densités (512 bits M512, 4 Kbits M4K et 512 Kbits
MegaRAM) sont réparties sur la matrice, ainsi que des blocs dits ”blocs DSP” apparaissant
sur la figure 28. Ces derniers intègrent des fonctions matérielles telles que multiplieurs, ac-
cumulateurs, additionneurs, multiplexeurs et registres et permettent, entre autre, de réaliser
des multiplieurs 36 bits ou des opérateurs MAC de 18 bits. Au niveau inférieur, les LABs sont
constitués de 8 ALM (Adaptive Logic Module) et d’un réseau de connexions locales. Les ALMs,
schématisés à la figure 29, sont réalisés autour d’un bloc de logique combinatoire à 8 entrées,
de deux additionneurs et des registres de sortie. Le bloc combinatoire est en fait réalisé avec
deux LUTs à quatre entrées et de quatre LUTs à trois entrées.

Figure 1.3 – Niveau supérieur de la hiérarchie de l’architecture du circuit Stratix II

1.4 Le processeur embarqué NIOS

Le processeur embarqué NIOS est un processeur à coeur logiciel de type firmcore , c’est
à dire exclusivement dédié à la famille d’Altera. Le processeur NIOS peut être associé à une
large gamme de périphériques, des instructions personnalisées et des accélérateurs pour créer
un SoPC . Le coeur logiciel de processeur embarqué NIOS est configurable et évolutif, pour
permettre aux intégrateurs systèmes de disposer d’une solution SoPC souple et très robuste. Ce
processeur peut être facilement combiné avec la logique d’utilisateur et être programmé dans
un FPGA.

5
 Figure 1.4 – Système Altera NIOS

La figure décrit le système NIOS. Il est constitué du processeur NIOS, du bus Avalon et
des périphériques (contrôleur mémoire, UART, timer. . . ). Le processeur NIOS est le coeur du
système, il est connecté aux différents périphériques à travers le bus Avalon. Ce bus doit être
configuré en maı̂tre/esclave. L’interface du bus Avalon est générée automatiquement par l’outil
de génération d’Altera NIOS (SOPC Builder).

1.4.1 Processeur NIOS

Le processeur NIOS est un processeur RISC entièrement synchrone, son architecture interne
de type Harvard. Il possède au maximum 6 niveaux de pipeline 1 cadencé à 50 MHz avec une
largeur de bus de 32 bits. Ses performances sont de 30 à 80 MIPS (Million Instructions per
Second). Il est possible d’accélérer certains traitements, en ajoutant des instructions person-
nelles (décrites en VHDL) au processeur NIOS. De cette manière, il est possible de réaliser de
la surcharge d’operateurs ou simplement d’étendre les jeux d’instruction. D’après la figure 34,
on voit bien qu’on peut ajouter à l’Unité Arithmétique et Logique (UAL) du processeur NIOS
essentiellement deux types d’instruction : combinatoire (un seul cycle) ou séquentiel (multi
cycle) .
1. selon versions du NIOS II

6
 Figure 1.5 – CPU NIOS

Figure 1.6 – Instruction personnalisée du processeur NIOS II

La société Altera propose trois versions pour le processeur NIOS II. La table illustre ces
trois versions. Une première version Economy qui utilise moins de surface, une deuxième version
Standard qui permet un compromis entre surface et rapidité, une dernière version Fast qui
est plus rapide que les deux autres.

NIOS II /f NIOS II /s NIOS II /e

Pipeline 6 niveaux 5 niveaux Non
Multiplication Matériel 1 Cycle 3 Cycle Par logiciel
Branch Prediction Dynamic Static Non
Cache d’Instructions Configurable Configurable Non
Cache de données Configurable Non Non
Instructions Personnalisés Supérieur à 256 Supérieur à 256 Supérieur à 256

7
 Figure 1.7 – Implantation du processeur NIOS II sur différents circuits FPGA d’Altera

La figure ci-dessus représente les performances en DMIPS (Dhrystons Million Instructions

per second, unité issue du benchmark dit de Dhrystons) et la surface occupée des différentes
versions du NIOS II sur différentes familles de FPGA d’Altera (Stratix II, Stratix, Cyclone).
D’après cette figure, on constate que l’implantation du processeur NIOS II (version Fast,
Standard et Economy) sur circuit FPGA Stratix II donne de meilleures performances (225
DMIPS@205 MHz, 133 DMIPS@180 MHz et 31 DMIPS @209 MHz respectivement) et une
occupation de surface la plus faible (1319 ALUTs, 1029 ALUTs et 483 ALUTs respectivement)
par rapport à un autre FPGA.

1.4.2 Bus Avalon

Le bus Avalon peut être vu comme un ensemble de signaux prédéfinis permettant de connec-
ter un ou plusieurs IP. La figure 36 présente le bus Avalon. Ce bus comprend un décodeur
d’adresse, un multiplexeur de données, un générateur de cycles d’attente et un contrôleur d’in-
terruption. Les utilisateurs peuvent facilement intégrer leurs propres périphériques avec le reste
du système basé sur le processeur NIOS.

8
 Figure 1.8 – Bus Avalon

Le bus Avalon permet la connexion entre des composants maı̂tres ou esclaves. Il supporte
plusieurs maı̂tres sur le bus. Un arbitrage est nécessaire au partage d’une même ressource
partagée par les circuits maı̂tres. Cette architecture multi maı̂tre fournit la grande flexibilité
dans la conception des systèmes.
Les figures représentent un exemple de déroulement des cycles de lecture et d’écriture (res-
pectivement) sur le bus Avalon du système.

Figure 1.9 – Cycle de lecture

(A) : Le cycle de lecture commence par un front montant de clk.

(B) : Le port maı̂tre fournit les signaux read(n) et address.
(C) : Le bus Avalon présente les données à lire readdata si le signal wait request est à “0 “.
(D) : Le port maı̂tre capture les données readdata sur le prochain front montant. Puis le
transfert se termine et un autre cycle peut recommencer.

Figure 1.10 – Cycle d’écriture

9
(A) : Le cycle d’écriture commence par un front montant de clk.
(B) : Le maı̂tre fournit les signaux address, write n et writedata.
(C) : si le signal wait request est à “0” sur le front montant de clk, alors le transfert se
termine et un autre cycle de lecture ou écriture peut recommencer.

10
Chapitre 2

CONCEPTION DU SYSTÈME
MULTIMÉDIA EMBARQUÉ

2.1 Introduction
Durant la conception d’un SoC, le concepteur aura à choisir le composant programmable
qui sera le coeur du système, la plupart des architectures sont basées sur des processeurs à
usage général. Ces processeurs sont extensibles du fait que beaucoup d’applications peuvent
y être implantées, tandis que les performances obtenues peuvent être inférieures à celles obte-
nues avec des processeurs dédiées à des applications spécifiques. Mais l’approche de conception
mixte logicielle/matérielle permet à l’application d’atteindre des performances inaccessibles aux
approches de conception classiques. Les réalisations logicielles sont préférées pour des raisons
d’évolution et de coût. Par contre, les réalisations matérielles sont dédiées aux fonctionnalités
nécessitant des circuits spécialisés ou des performances élevées.

Figure 2.1 – Conception traditionnelle et codesign

Le codesign implique donc une conception en même temps du matériel et du logiciel. La

figure 41 illustre la différence entre la méthodologie de conception traditionnelle et le code-
sign. En fait, dans la conception traditionnelle, la définition de l’architecture est suivie par le
découpage des tâches qui vont être réalisées par les équipes du matériel et du logiciel. L’équipe
du matériel réalise une description du système en utilisant un langage de description matériel
tel que le VHDL ou le Verilog. Puis elle réalise la synthèse et la génération des circuits intégrés
en utilisant des outils de CAO. L’équipe du logiciel est responsable de l’écriture du code qui

11
va être compilé et exécuté sur des processeurs d’usage général. Ensuite, les équipes réalisent
l’intégration physique des deux parties.
Mais, on constate que le manque d’interaction entre ces deux équipes pendant les étapes de
développement peut générer plusieurs problèmes d’intégration. Dans , il est rapporté que 71.5%
des projets système embarqué n’atteignent pas 30 % des performances attendues durant la
phase de conception.
Ces problèmes peuvent être évités par l’utilisation d’une méthodologie de conception conjointe
logicielle/matérielle. En effet, les équipes du logiciel et du matériel travaillent ensemble et
à chaque étape de conception, elles réalisent l’intégration et le test des spécifications. Les
opérations de test et d’intégration génèrent une augmentation du temps de conception. L’intégration
finale lors du prototypage est réalisée sans difficulté. On constate que la méthodologie de concep-
tion conjointe réduit le temps total de conception puisqu’elle réduit le nombre de retours à des
étapes antérieures de conception provoqués par la détection d’erreur.

2.2 Plateforme matérielle de traitement vidéo

2.2.1 Introduction
Cette partie est consacré à l’étude et à la conception d’une plateforme matérielle d’acqui-
sition, de traitement et de restitution vidéo servant de préalable à toute étude d’algorithme
de traitement vidéo. La plateforme matérielle s’articule autour de la carte Cyclone II d’Al-
tera complétée d’une interface caméra et d’une interface LCD 2”2. Le coeur du système met
en oeuvre le module IP NIOS II d’Altera dans l’environnement de développement Quartus II
d’Altera. Les modules IPs d’acquisition, restitution vidéo ainsi que des modules IPs de base
nécessaires (module PIO, I2C) ont été développés. des application en C ont été utilisé pour le
contrôle logiciel de la plateforme matérielle. Enfin, l’ensemble des blocs IPs a servi à constituer
une bibliothèque.

2.2.2 Conception d’un système SoPC

Quartus II est un logiciel proposé par la société Altera permettant la gestion complète d’un
flot de conception FPGA. La figure présente l’interface graphique de Quartus II.

12
 Figure 2.2 – Quartus II 11.0 SP1 interface

Ce logiciel permet de faire une saisie graphique ou une description VHDL/Verilog d’archi-
tecture numérique, d’en réaliser une simulation en utilisant le simulateur ModelSim de Mentor
Graphics, une synthèse et une implantation sur FPGA. Il comprend une suite de fonctions de
conception au niveau système permettant d’accéder à la large bibliothèque d’IPs d’Altera et
un moteur de placement/routage intégrant la technologie d’optimisation et des solutions de
vérification. D’une manière générale, un flot de conception ayant pour but la configuration de
composants programmables se déroulent de la manière suivante

Figure 2.3 – Flot de conception

13
 L’IDE (Integrated Design Entry) Quartus II intègre l’outil SOPC Builder qui permet de
construire un système SoPC intégrant divers périphériques d’E/S tels que le processeur NIOS
II, les contrôleurs de SRAM et de SDRAM, un contrôleur DMA (Direct Memory Access). . . De
même, on peut intégrer son propre composant dans le design sous forme d’un bloc IP externe
(Interface caméra, LCD ,VGA. . . ). On peut ainsi intégrer autant de périphériques que l’on
veut, n’étant limité que par le nombre de broches et de cellules logiques du circuit FPGA. Le
mapping mémoire et le niveau des interruptions du design sont fixés durant cette phase. La
figure montre la mise en oeuvre de l’outil SOPC Builder. C’est en fait la première passerelle
avec le logiciel embarqué.

Figure 2.4 – SOPC Builder et mapping mémoire

A l’issue de la phase de construction du système SoPC, Quartus II génère le projet en

intégrant tous les modules IPs. Après synthèse, on a le fichier de programmation du circuit
FPGA correspondant au design SoPC mais aussi un kit de développement logiciel qui comprend
tous les fichiers en langage C (.h et .c) pour piloter les périphériques d’E/S d’Altera. C’est
en fait la deuxième passerelle avec le logiciel embarqué. L’offre de codesign apparaı̂t ici avec la
possibilité de développer une partie de l’application par matériel ou de le faire en logiciel par
langage C.

14
2.3 Platforme de développement : CycloneII FPGA Mul-
timedia board
Plate-forme Cyclone II multimédia est un outil pour tout ce qu’il couches : Débutant, pré-
intermédiaire et avancé. Ses modules complémentaires fournissent la conjonction de l’école et
les concepteurs de l’entreprise. L’utilisateur peut mettre en œuvre VLSI (Very Large Scale
Intégration) ... avec DHL, la conception de circuit logique numérique et de réaliser davantage
l’ les médias numériques et le processeur d’image

Figure 2.5 – CycloneII FPGA Multimedia board

2.3.1 Caractéristique générale

1. high porte comptage EP2C35 FBGA 672 Cyclone II FPGA puce
- 90 processus de nm, est une puce de la force de FPGA Altera
- Fournir 70 dix mille le nombre de portes. (Tout Xilinx FPGA 140 dix mille espace de
niveau)
- circuit de distribution d’horloge fourni, jusqu’à la performance de la conception du
système, de réduire Clock Skew
- Provid DSP Block, jusqu’à exécution de l’opération
2. Quatre séries 384K byte Frame Buffer mémoire
- Il peut données d’image provisoires à 2,0 Panel ”LCD ou VGA
3. Deux séries 1M octets de SRAM Meomory
- Il peut stocker l’image du capteur image CMOS capture
4. Un ensemble LPTS 2,0 pouces haute de pixels du panneau LCD
- haute résolution (dot) : 320 (W) x240 (H)
5. Capteur d’image CMOS
- 30ten milliers de pixels à la capture d’iamge actif / statique (fonction de mise au point)
6. Deux séries de ports de sortie PS2
- Contrôle du clavier et de la souris

15
 7. Deux ensembles de ports de sortie audio
- design audio numérique
8. A 24 bits mis DAC vidéo, support 80MSPS opération, avec un port de sortie
VGA
9. Six séries 7 LEDs segment
- chronomètre, compteur de la fin, compteur, alarme
10. 24 ensembles d’auto-définition LED
- Mettre en œuvre le ticker LED
11. 16 séries de boutons-poussoirs auto-définition
12. séries de commutateurs DIP
13. 8 paires de cristaux pour les utilisateurs : mettre en œuvre la conception du
système de l’horloge multiple avec la variété de users’demands
14. PLL (Phase Lock Loop) sortie d’horloge
- concevoir l’horloge de sortie du système avec le logiciel “Quartus II”
15. Fournir mode USB ByteBlaster JTAG et AS (Active Serial)

Figure 2.6 – CycloneII FPGA Multimédia board multimédia composantes

16
2.4 Système d’acquisition et de traitement vidéo
Nous avons conçu et réalisé une plateforme matérielle d’acquisition de traitement et de
restitution vidéo servant à l’évaluation de notre méthodologie de conception logicielle/matérielle
pour les systèmes multimédia embarqués . La figure représente notre plateforme.

Figure 2.7 – Notre système d’acquisition, traitement et restitution vidéo

2.5 Principe de base de traitement d’image

2.5.1 Définition d’une image et des types d’images
Une image est stockée en mémoire sous forme de collection de points élémentaires appelés
pixels. Nous pouvons considérer une image numérique comme une page de nombres organisés
en tableau ou en matrice. Chaque nombre représente les caractéristiques du pixel. La position
de chaque pixel peut être exprimée par deux coordonnées sur l’axe horizontal X et l’axe vertical
Y comme le montre la figure ci-dessous.

Figure 2.8 – Elément d’une image : le pixel

Le codage d’un pixel dépend du type d’image et nous en recensons trois types :
1. Les images à deux niveaux : une image en noir et blanc est l’exemple le plus courant.
Toute image décrite avec deux valeurs correspond à ce type. Un bit suffira pour coder la
valeur d’un pixel.
2. Les images à plusieurs niveaux de gris : les images de nos téléviseurs en noir et blanc
sont de ce type. La plupart des systèmes définissent 256 niveaux de gris. Mais, seuls 128
niveaux de gris sont détectables par l’oeil.

17
 3. Les images couleurs : la couleur peut être codée, soit par composition de couleurs pri-
maires, soit par composition d’informations de luminance et de chrominance. En fait, une
couleur peut être représentée par un ensemble de trois coordonnées, c’est-àdire qu’une cou-
leur peut être reproduite par la superposition de trois couleurs primaires comme montre
la figure 4. Le système RVB (Rouge-Vert-Bleu ou ≪ RGB ≫) utilise les couleurs primaires :
rouge, vert et bleu. La valeur du pixel doit représenter les composantes trichromatiques
de la couleur. En général, nous disposons de huit bits pour coder une composante, soit 24
bits pour coder la valeur d’un pixel. Ce système RVB peut donc définir plus de 16 millions
de couleurs. Des résultats expérimentaux ont prouvé que l’oeil est beaucoup plus sensible
aux variations fines d’intensité lumineuse (luminance) qu’à celles de la couleur (chromi-
nance). Il en résulte que nous pouvons nous contenter de transmettre l’information de
couleur avec moins de détails que l’information de luminance.

Figure 2.9 – Superposition des trois couleurs : rouge, vert et bleu

2.5.2 Changement d’espace de couleur

Toute longueur d’onde visible peut être visuellement simulée en convoluant le signal avec les
fonctions de sensibilité des trois différents capteurs rétiniens du système visuel humain dit LMS
(Large=565nm dit rouge, Medium=535nm dit vert, Short=430nm dit bleu). Dans le cas d’une
compression avec perte, la reconstruction de chaque bande (RVB) risque de ne pas appréhender
les structures de l’image de la même façon, engendrant différentes erreurs de reconstruction et
par la même, de fausses couleurs visuellement choquantes. On préféra donc un espace de lumi-
nance et chrominance rouge et bleu YCrCb (ou YUV) où les primaires sont décorrélées, ce qui
offre l’avantage de séparer les informations d’intensité lumineuse et de couleur. Un tel espace
permet de gérer les premières avec plus de soin. A titre d’exemple, voici la matrice de passage
de l’espace RVB à l’espace YUV :

2.5.3 Définition de la vidéo

La vidéo est une succession d’images animées. Le principe fondamental de la vidéo est que
l’oeil humain a la possibilité de retenir pendant un certain temps (de l’ordre du dixième de
seconde) toute image imprimée sur la rétine. Il suffit donc de faire défiler un nombre suffisant

18
d’images par seconde, pour que l’oeil ne se rende pas compte qu’il s’agit d’images distinctes. Il
existe deux grandes familles de systèmes vidéo : les systèmes vidéo analogiques et les systèmes
vidéo numériques.

La vidéo analogique
La caméra balaye l’image bidimensionnelle qu’elle a devant elle par un faisceau d’électrons
qui se déplace très rapidement de gauche à droite et plus lentement de haut en bas et produit
une tension en fonction du temps. Elle enregistre ainsi l’intensité lumineuse, et à la fin du
balayage, on a alors une trame. Le faisceau revient à l’origine pour recommencer. Le récepteur
va recevoir cette intensité en fonction du temps, et pour reconstruire l’image, va répéter le
processus de balayage.
Les paramètres précis de ce balayage varient d’un pays à l’autre mais deux grandes familles
existent :
En Europe (système PAL/SECAM, pour Phase Alternating Line / SEquentiel Couleur Avec
Mémoire) ce système utilise 625 lignes (seulement 576 sont affichées), un rapport vertical/ho-
rizontal de 4/3 et un débit de 25 images par seconde.
En Amérique et au Japon (système NTSC, pour National Television Standards Committee),
on a seulement 525 lignes (483 affichées) et un débit de 30 images par seconde

Figure 2.10 – Principe de balayage utilisé pour la vidéo et la télévision

La vidéo numérique
La vidéo numérique est tout simplement une suite d’images formées d’une matrice de pixels.
Pour obtenir des images en couleur, il faut utiliser au moins 8 bits par pixel, ce qui correspond
à 256 couleurs. En fait, avec 8 bits par pixel, on obtient de la vidéo numérique noir et blanc
de haute qualité. Pour la vidéo numérique couleur, on utilise 8 bits pour chaque couleur RVB,
soit donc 24 bits par pixel, ce qui correspond à environ 16,8 millions de couleurs. Le principe
de balayage utilisé est similaire à celui de la vidéo analogique.

19
Chapitre 3

RÉALISATION DU SYSTÈME

Pour réalisé notre système multimédia embarquée on se basons sur les fichiers HDL fournit
par le constructeur de notre carte cible .
Ces fichier HDL sont écrit en Verilog est ont décrit les deux interface de capteurs CMOS
pour l’utilisé comme un slave de I2C : CMOS2BUFFER.v , et CMOSI2C.v et un troisième fichier
de contrôler l affichage de l’LCD DispCntl.v .

3.1 Configuration de capteur CMOS

Le capteur CMOS est camera de mille pixels 640x480 , qui peut effectuer 644x484 au format
de données brutes peut être manuelle ciblée.

Figure 3.1 – inputs/ouputs de capteur CMOS

afin d’avoir démarrer le capteur camera il faut le configuré pour obtenir la sortie désiré .
le processeur de camera contienne un jeu d’instruction qui assure la configuration de ce
dernier :

20
 Figure 3.2 – registres d’instructions de capteur CMOS

Alors in faut toujours inclue dans notre système une ROM de 16x32 pour assurer notre
configuration d’image et de communication I2C ,pour cela on utilise MegaFunctionCore pour
fournir la ROM et un fichier .mif pour l’inutilisé
La caméra sera chargée bien entendu de capturer un flux d’image et devra être configurée
pour fournir les données sur 8 bits sous le format RGB qui est le plus facile à gérer.

Figure 3.3 – configuration du camera

21
3.2 Notre Système
pou mieux optimisé notre système on a choisit cette architecture dans la quelle le processeur
NIOS II communique avec la camera (SDRAM) et l’LCD par l’intermédiaire des IP de PIO :
parllele input output

Figure 3.4 – notre système NIOS

les information image sont enregistré dans les SRAM de 1Mo par les les entités de CMOS
et le sortie de notre système fournie l’image traité a l’interface de l’LCD

22
 Figure 3.5 – vue d’ensemble de notre système NIOS

3.3 création de système sur quartus II et SoPC builder

afin de satisfait notre vision on utilisons SoPC builder pour crée le processeur NIOS et leurs
périphériques :

23
 Figure 3.6 – le processeur NIOS et leurs périphériques

Après avoir généré les IP on s’intéresse a établir la connexion entre les différentes compo-
santes du système et les association des PIN avec les PIN réel de la pus cyclne II on utilisons
le guide de la carte , et en plus des PIN de capteur CMOS et l’LCD on utilise aussi le PIN N26
pour la clock de système et U24 pour la reset globale.

Figure 3.7 – le schéma block de notre système

3.4 Le premier test : Hello World !

après avoir téléchargé le fichier .sof généré par la compilation de notre système , on passe
a NIOS IDE pour commencé à programmer le NIOS II .

24
 pour notre premier test on va seulement affiché “Hello world ! “ dans le consol NIOS , pour
sela on créé un nouveau BSP projet dans NIOS IDE avec le fichier de configuration de notre
SoPC .
Deux projet sont crée le premier sé’est le projet qu’on va modifier le deuxième est le projet
contienne les fichier de drivers des différent composantes du SoPC ( PIO , RAM , JTAG ...)

1 #include <stdio.h>
2

3 int main()
4 {
5 while(1)
6 printf("Hello from ENSAK !\n");
7

9 return 0;
10 }
11

12 }

Figure 3.8 – Hello world

dans le cadre de debuggé ce programme on rencontre plusieurs problème :

1. le NIOS fast est nécessite un licence pour l’utiliser un message d’erreur s’affiche si on essai
de l’implémenté sur la carte ,alors on se limite par NIOS/e
2. la mémoire ram de 40K peut être saturé par des grand code , et les deux SDRAM dans
la carte est déjà utilisé comme un buffer de camera

25
 3.5 Programme de traitement d’image
3.5.1 L’algorithme
Seul un type de traitement a été étudié et appliqué sur l’image fournie par la caméra.
Ce traitement consiste simplement à faire un seuillage sur une des 3 composantes d’un
pixel. Pour ce faire, l’idée est la suivante : on regarde si la somme des 3 composantes est
inférieure à 3 fois la composante que l’on veut garder. Si c’est le cas, on place la valeur
de 255 sur la composante que l’on veut faire ressortir et on met à 0 les autres.
Exemple : On souhaite faire ressortir le bleu dans l’image.
Si :
3.B > R + G + B
alorsB = 255; R = G = 0
Sinon on ne touche pas aux composantes du pixel.

3.5.2 les fonctions de altera avalon pio regs.h

le fichier altera avalon pio regs.h contienne le fonction de manipulation du PIO soit
écrire dans un PIO ou lire d’apré un autre
IOWR ALTERA AVALON PIO DATA(x,BASE) cette fonction faire l’écriture de x sur le PIO de
l’dresse de base de BASE .
IORD ALTERA AVALON PIO DATA(BASE) cette fonction faire lire de PIO de l’dresse de base
de BASE .

3.6 L’implémentation du programme

cette algorithme simple , fait un bon choix pour mieux comprendre les outils de program-
mation de NIOS sans effort plus sur la complexité de l’algorithme .

1 /*
2 * FORCAGEb.c
3 *
4 * Created on: 17 juin 2013
5 * Author: yAcine
6 */
7 #include <stdio.h>
8 #include"system.h"
9 #include "altera avalon pio regs.h"
10

11 #define WRITE(x) (IOWR ALTERA AVALON PIO DATA(x,CAMERA BASE))

12 #define READ (IORD ALTERA AVALON PIO DATA(LCD BASE))
13

14 int main()
15 {
16 //RGB 8 bit
17 unsigned char Color;
18 unsigned char R;
19 unsigned char G;
20 unsigned char B;

26
21 //printf("Hello from Nios II!\n");
22 while(1)
23 {
24 if(READ=0x0)
25 WRITE(0xFFFF);
26 else
27 {
28 R=READ;
29 delay ms(D);
30 G=READ;
31 delay ms(D);
32 B=READ;
33 delay ms(D);
34 }
35

36 if(3*B>R+G+B)
37 {
38 R=0; //0x0000
39 G=0; //0x0000
40 B=255; //0xFFFF
41 }
42

43 WRITE(R);
44 delay ms(D);
45 WRITE(G);
46 delay ms(D);
47 WRITE(B);
48 delay ms(D);
49

50

51 }
52 return 0;
53 }

27
Conclusion

Au cours de cette étude, on a présenté le développement d’une plateforme matérielle d’ac-

quisition et de restitution vidéo en Temps Réel en utilisant la conception mixte logicielle
matérielle. Cette plateforme se base sur la carte de développement Cyclone II d’Altera qui est
connectée à la carte d’interface caméra et à celle de l’interface LCD. Le cœur du système est le
processeur embarqué NIOS II d’Altera. Les modules IPs d’acquisition et de restitution vidéo
ont été développés afin d’interfacer les deux modules externes avec la carte de développement.
On a pu voir en outre que la mise en oeuvre d’un application avec NIOS IDE sur le pro-
cesseur NIOS II pour assuré le traitemet d’image mais cette application reste insuffisant pour
des application avancé en terme de complexité et en terme d’ordonnancement . Alors il est
important d’implémenter un système d’exploitation comme uClunix ,RT Linux,RTOS ou RTEMS

28