You are on page 1of 33

´ CONCEPTION ET IMPLEMENTATION DU ` ´ ´ SYSTEME MULTIMEDIA EMBARQUE

ECOLE NATIONALE DES SCIENCES APPLIQUEED DE KHOURIBGA 2´ em´ e Ann´ ee cycle ing´ enieur : G´ enie Electrique Encadr´ e par :Mr. Ismail Laghrat Siham Darif Rabiaa Manar Sliman Ennayri Yacine a.Amkassou Omar Barmaki

Remerciements
Nous tenons a ` remercier dans un premier temps, toute l’´ equipe p´ edagogique de l’Ecole Nationale des Sciences Appliqu´ ees de Khouribga , pour avoir assur´ e la partie th´ eorique de notre formation. Nous remercions ´ egalement M. Ismail Laghrat pour l’aide et les conseils qu’il nous a apport´ e lors des diff´ erentes ´ etapes de l’´ elaboration de notre projet. Nous tenons a ` vous remercier du fond du cœur ´ egalement pour chaque minute pass´ ee avec nous ; pour chaque information et pour chaque nouvelle le¸ con que vous avez enseign´ ee. On sait bien que n’a pas ´ et´ e du facile de nous enseigner ; parfois dˆ ua ` notre manque de base d’autre fois ` a notre surcharge, merci de ne pas avoir baiss´ e les bras quand mˆ eme ; de nous avoir tant soutenu et encourager pour arriver au bout, que Dieu vous b´ enisse.

1

Table des mati` eres
` ´ ´ 1 LA CONCEPTION DES SYSTEMES EMBARQUEES NUMERIQUES 1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 M´ ethodologies de Conception des syst` emes num´ eriques . . . . . . . . . . . . 1.2.1 G´ en´ eralit´ es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.2 R´ ealisation d’un syst` eme sur puce SoC ou SoPC . . . . . . . . . . . 1.2.3 Les diff´ erentes familles de blocs IP . . . . . . . . . . . . . . . . . . . 1.3 Les circuits a ` logique programmable . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 Types d’architectures et ´ el´ ements des circuits FPGA . . . . . . . . . 1.3.2 Exemple de circuit FPGA : la famille Altera cyclone II . . . . . . . . 1.4 Le processeur embarqu´ e NIOS . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1 Processeur NIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.2 Bus Avalon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ` ´ ´ 2 CONCEPTION DU SYSTEME MULTIMEDIA EMBARQUE 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Plateforme mat´ erielle de traitement vid´ eo . . . . . . . . . . . . . . 2.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Conception d’un syst` eme SoPC . . . . . . . . . . . . . . . 2.3 Platforme de d´ eveloppement : CycloneII FPGA Multimedia board 2.3.1 Caract´ eristique g´ en´ erale . . . . . . . . . . . . . . . . . . . 2.4 Syst` eme d’acquisition et de traitement vid´ eo . . . . . . . . . . . . 2.5 Principe de base de traitement d’image . . . . . . . . . . . . . . . 2.5.1 D´ efinition d’une image et des types d’images . . . . . . . . 2.5.2 Changement d’espace de couleur . . . . . . . . . . . . . . . 2.5.3 D´ efinition de la vid´ eo . . . . . . . . . . . . . . . . . . . . . ´ ` 3 REALISATION DU SYSTEME 3.1 Configuration de capteur CMOS . . . . . . . . . . 3.2 Notre Syst` eme . . . . . . . . . . . . . . . . . . . . . 3.3 cr´ eation de syst` eme sur quartus II et SoPC builder 3.4 Le premier test : Hello World ! . . . . . . . . . . . . 3.5 Programme de traitement d’image . . . . . . . . . 3.5.1 L’algorithme . . . . . . . . . . . . . . . . . . 3.5.2 les fonctions de altera avalon pio regs.h . . . 3.6 L’impl´ ementation du programme . . . . . . . . . . Conclusion 1 1 1 1 3 3 4 4 4 5 6 8 11 11 12 12 12 15 15 17 17 17 18 18 20 20 22 23 24 26 26 26 26 28

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

2

Table des figures
1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 Evolution de la conception num´ erique . . . . . . . . . . . . . . . . . . . . . SoC bas´ e coeurs de processeurs . . . . . . . . . . . . . . . . . . . . . . . . Niveau sup´ erieur de la hi´ erarchie de l’architecture du circuit Stratix II . . Syst` eme Altera NIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CPU NIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Instruction personnalis´ ee du processeur NIOS II . . . . . . . . . . . . . . . Implantation du processeur NIOS II sur diff´ erents circuits FPGA d’Altera Bus Avalon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cycle de lecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cycle d’´ ecriture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conception traditionnelle et codesign . . . . . . . . . . . . . Quartus II 11.0 SP1 interface . . . . . . . . . . . . . . . . . Flot de conception . . . . . . . . . . . . . . . . . . . . . . . SOPC Builder et mapping m´ emoire . . . . . . . . . . . . . CycloneII FPGA Multimedia board . . . . . . . . . . . . . CycloneII FPGA Multim´ edia board multim´ edia composantes Notre syst` eme d’acquisition, traitement et restitution vid´ eo El´ ement d’une image : le pixel . . . . . . . . . . . . . . . . Superposition des trois couleurs : rouge, vert et bleu . . . . Principe de balayage utilis´ e pour la vid´ eo et la t´ el´ evision . . inputs/ouputs de capteur CMOS . . . . registres d’instructions de capteur CMOS configuration du camera . . . . . . . . . notre syst` eme NIOS . . . . . . . . . . . vue d’ensemble de notre syst` eme NIOS . le processeur NIOS et leurs p´ eriph´ eriques le sch´ ema block de notre syst` eme . . . . Hello world . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3 5 6 7 7 8 9 9 9 11 13 13 14 15 16 17 17 18 19 20 21 21 22 23 24 24 25

3

R´ esum´ e Le sujet de ce projet est la contribution au d´ eveloppement et a ` la conception d’un syst` eme multim´ edia embarqu´ e en utilisant la m´ ethodologie de conception conjointe logicielle/mat´ erielle (codesign ). Il en a d´ ecoul´ e la constitution d’une biblioth` eque des modules IP (Intellectual Property) pour les applications vid´ eo. Dans ce contexte, une plateforme mat´ erielle d’acquisition et de restitution vid´ eo a ´ et´ e r´ ealis´ ee servant de pr´ ealable ` a l’´ evaluation de la m´ ethodologie de conception en codesign et a ` toute ´ etude d’algorithme de traitement vid´ eo. On s’est int´ eress´ e en particulier a ` l’´ etude et a ` l’implantation de la . La fr´ equence de fonctionnement de la plateforme est de 25 MHz. L’ensemble du d´ eveloppement est ex´ ecut´ e par le processeur NIOS II sous un application d´ evelopper a l aide de NIOS IDE .

Chapitre 1 ` LA CONCEPTION DES SYSTEMES ´ ´ EMBARQUEES NUMERIQUES
1.1 Introduction

Les avanc´ ees actuelles dans la technologie des semi-conducteurs et des m´ ethodologies de conception permettent le d´ eveloppement de syst` emes num´ eriques complexes sur puce SoPC, des dispositifs pouvant contenir des millions de transistors. Les derniers circuits FPGA (Field Programmable Gate Array) permettent ´ egalement le d´ eveloppement de syst` emes complets. Ainsi, un syst` eme qui ´ etait auparavant implant´ e sur une carte, peut dor´ enavant ˆ etre con¸ cu sur une puce unique offrant l’avantage d’ˆ etre compact et de supporter un tr` es grand nombre de traitements arithm´ etiques. La tendance actuelle est donc ` a l’assemblage dans une mˆ eme puce de plusieurs composants ´ eventuellement h´ et´ erog` enes pour r´ epondre au mieux aux exigences des syst` emes multim´ edia embarqu´ es. Ces composants peuvent ˆ etre aussi bien des coeurs de processeurs, des coeurs de DSP, des acc´ el´ erateurs mat´ eriels... La r´ ealisation de ces syst` emes a n´ ecessit´ e la mise en place d’une m´ ethodologie de conception logicielle/mat´ erielle (codesign) prenant en compte les contraintes de l’embarqu´ e.

1.2
1.2.1

M´ ethodologies de Conception des syst` emes num´ eriques
G´ en´ eralit´ es

Dans l’approche traditionnelle, un syst` eme num´ erique est un assemblage sur une carte de diff´ erents composants discrets repr´ esentant chacun une fonction particuli` ere plus ou moins complexe telle qu’additionneur, m´ emoire, composant d’interface, gestionnaire d’interruption, processeur... Si une erreur de conception ´ etait faite, il ´ etait au minimum n´ ecessaire d’ajouter des fils entre les composants, ou au pire, de refaire une carte pour r´ egler le probl` eme, c’esta `dire reprendre compl` etement son routage. Plus le syst` eme num´ erique est complexe, plus ces composants sont nombreux, plus la carte est ch` ere, et plus les perturbations ´ electromagn´ etiques 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´ erique. En effet, moins il y a de composants remplissant un mˆ eme cahier des charges, moins la carte est ch` ere, et plus les fonctions sont int´ egr´ ees, plus il est possible de proposer une carte moins encombrante. Les am´ eliorations des processus de fabrication des composants ´ electroniques ont permis de r´ epondre de mieux en mieux ` a ces besoins. Dans ce contexte, l’International Technology Roadmap for Semiconductors affirme que les 1

processeurs contiennent en moyenne pr` es de 100 millions de transistors en 2007 et en pr´ evoit pr` es de 1.5 milliard pour 2013. L’´ evolution des technologies de fabrication de circuits permettent l’int´ egration d’un syst` eme num´ erique sur un mˆ eme composant : c’est le concept du single chip. Ceci est en fait li´ ea ` la loi empirique de Moore qui stipule que pour une surface de silicium donn´ ee, on double le nombre de transistors int´ egr´ es tous les 18 mois . La loi de Moore a radicalement chang´ e la fa¸ con de concevoir les syst` emes num´ eriques aujourd’hui puisque l’on peut proc´ eder ` a l’implantation d’algorithmes complexes pour les syst` emes num´ eriques de futures g´ en´ erations. On travaille maintenant au niveau syst` eme (ou fonctionnalit´ e) et non au niveau porte logique. Cette ´ evolution de la conception peut ˆ etre r´ esum´ ee sur la figure

Figure 1.1 – Evolution de la conception num´ erique L’approche “sch´ ematique” au niveau portes logiques et fonctions de base RTL (Register Transfer Logic) semble aujourd’hui d´ elaiss´ ee pour la conception des syst` emes complexes au profit d’une approche “textuelle”. L’approche sch´ ematique reste cependant toujours valable et est plutˆ ot r´ eserv´ ee a ` la conception des petits syst` emes... L’approche textuelle, on utilise des langages de description de mat´ eriel comme VHDL (Very high speed integrated circuit Hardware Description Language) ou Verilog pour synth´ etiser une fonction num´ erique. Ces langages de description de mat´ eriel sont en fait des langages de programmation qui sont utilis´ es conjointement avec un compilateur ou un simulateur. Ces langages deviennent un standard et leur choix participe ainsi a ` la p´ erennit´ e du produit. Il existe ` a l’heure actuelle d’excellents synth´ etiseurs mixtes et multi-technologiques (par exemple Precision de Mentor Graphics). Les fabricants de FPGA proposent maintenant leur propre synth´ etiseur. Dans le d´ eveloppement des syst` emes num´ eriques complexes, il existe des besoins qui reviennent fr´ equemment. Certaines soci´ et´ es ont d´ evelopp´ e ou rassembl´ e des modules r´ epondant a ` ces besoins et les mettent sur le march´ e sous le nom de blocs IP (Intellectual Property) (fonctions math´ ematiques : FFT, DCT, FIR, interfaces bus : PCI, RapidIO, coupleurs divers : UART, HDLC. . . ). Ces modules IP peuvent ˆ etre achet´ es ou t´ el´ echarg´ es librement sur Internet. On peut ainsi voir la conception d’un syst` eme num´ erique complexe comme un assemblage de modules IP Les langages de description de mat´ eriel sont aussi int´ eressants pour la facilit´ e de modification et de r´ eutilisation d’un design pr´ ec´ edent pour un nouveau design : c’est le design reuse. 2

1.2.2

R´ ealisation d’un syst` eme sur puce SoC ou SoPC

Un SoC est un ensemble de blocs fonctionnels int´ egr´ es dans un composant ´ electronique avec au moins un processeur comme ´ el´ ement de traitement. La figure repr´ esente un SoC qui est bas´ e sur des coeurs de processeurs. A partir de cette figure, on constate que seuls les L’approche

Figure 1.2 – SoC bas´ e coeurs de processeurs SoC a ´ et´ e cr´ e´ ee dans un premier temps pour le d´ eveloppement d’ASIC mais a ´ et´ e´ etendue pour le d´ eveloppement de FPGA. On parle alors de SoPC pour System on Programmable Chip. Le SoC peut ˆ etre retenu pour les applications destin´ ees 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 ´ etapes longues et coˆ uteuses . De plus, un SoC est fig´ e et n’est donc pas r´ eutilisable pour une autre application. Par contre, le SoPC est un composant reconfigurable a ` volont´ e. Il permet donc un d´ eveloppement et prototypage rapide du syst` eme. Mais, en contrepartie, on peut avoir une consommation d’´ energie plus grande avec une performance plus faible que celle du SoC.

1.2.3

Les diff´ erentes familles de blocs IP

Un bloc ou un composant IP est un composant virtuel qui peut apparaˆ ıtre sous diff´ erentes formes IP Logiciel softcore : le composant est livr´ e sous sa forme HDL (Hardware Design Language) synth´ etisable, c’est ` a dire flexible. Son principal avantage est sa portabilit´ e. La propri´ et´ e du fichier source est en soi la meilleure documentation. On peut ainsi maintenir le produit pendant des ann´ ees et ´ eventuellement modifier la source et mˆ eme changer de technologie cible. L’inconv´ enient majeur est qu’il ne peut ˆ etre pr´ edictif en termes de superficie, puissance et temps. Le travail d’optimisation du circuit final est ` a la charge de l’int´ egrateur du syst` eme. IP Mat´ eriel hardcore : Dans ce cas, le bloc IP est cibl´ e sur une technologie particuli` ere et le travail d’optimisation est garanti. Cela englobe la netlist enti` ere, le routage et l’optimisation pour une librairie technologique sp´ ecifique, un layout personnalis´ e. L’inconv´ enient est qu’il est moins flexible car le processus est d´ ependant de la technologie. Par contre il a l’avantage d’ˆ etre pr´ edictif.

3

IP Firm firmcore : Le bloc IP firmcore offre un compromis entre le softcore et le hardcore, plus flexible que le hardcore, plus pr´ edictif en termes de performance et de surface que le softcore. En g´ en´ eral, le travail de synth` ese HDL est d´ ej` a r´ ealis´ e pour une technologie cible donnant lieu a ` une description par netlist (format EDIF par exemple).

1.3

Les circuits ` a logique programmable

Actuellement, on trouve diff´ erentes familles de circuits programmables tels que les CPLDs (Complex Logic Programmable Device) et les FPGAs. La diff´ erence entre ces deux types de composants est structurelle. Les CPLDs sont des composants pour la plupart reprogrammables ´ electriquement ou ` a fusibles, peu chers et tr` es rapides (fr´ equence de fonctionnement ´ elev´ ee) mais avec une capacit´ e fonctionnelle moindre que les FPGA. Par contre, ceux-ci sont des composants VLSI constitu´ es de blocs m´ emoires vives, enti` erement reconfigurables. Ces blocs sont structur´ es en LUT (Look Up Table), flip-flop, RAM et l’ensemble dispose d’un vaste syst` eme d’interconnexions. Le progr` es de la conception des circuits ´ electroniques permet d’avoir des composants toujours plus rapides et ` a plus haute densit´ e d’int´ egration, ce qui permet de programmer des ap` l’heure actuelle, on compte plications importantes comme par exemple les applications vid´ eo. A une dizaine de fabricants, le march´ e´ etant nettement domin´ e par les soci´ et´ es Altera et Xilinx

1.3.1

Types d’architectures et ´ el´ ements des circuits FPGA

Classiquement pour les architectures des circuits FPGA, on peut rencontrer trois topologies diff´ erentes : Architecture de type ˆ ılots de calcul D` es le d´ epart, Xilinx a choisi ce type d’architecture. Cette architecture FPGA est constitu´ ee d’une matrice plane d’´ el´ ements. Ces ´ el´ ements constituent les ressources logiques et de routages programmables du FPGA. Architecture de type hi´ erarchique Dans cette architecture, il existe plusieurs plans dans le FPGA. Mais, ces plans ne sont pas physiques, ils correspondent aux niveaux de hi´ erarchie logique. C’est a ` dire qu’un ´ el´ ement d’un niveau logique peut contenir des ´ el´ ements de niveau logique inf´ erieur, d’o` u la notion de hi´ erarchie. Chaque niveau logique reprend la topologie d’une architecture du type ˆ ılots de calcul avec un routage d´ edi´ e 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´ e au d´ ebut de l’ann´ ee 2004 un nouveau composant le Stratix II. Ce composant est marqu´ e par un certain nombre de changements par rapport aux architectures classiques des premiers FPGA Altera (Flex et Apex) a ` trois niveaux de hi´ erarchie. Le circuit Stratix II comme le circuit Stratix dont il a h´ erit´ e de nombreuses caract´ eristiques, est moins hi´ erarchique et n’a plus que deux niveaux de hi´ erarchie. Le niveau le plus haut (figure 27) consiste en un ensemble d’´ el´ ements configurables LAB (Logic Array Bloc) qui sont r´ epartis en matrice. A ce 4

mˆ eme niveau, des m´ emoires de diff´ erentes densit´ es (512 bits M512, 4 Kbits M4K et 512 Kbits MegaRAM) sont r´ eparties sur la matrice, ainsi que des blocs dits ”blocs DSP” apparaissant sur la figure 28. Ces derniers int` egrent des fonctions mat´ erielles telles que multiplieurs, accumulateurs, additionneurs, multiplexeurs et registres et permettent, entre autre, de r´ ealiser des multiplieurs 36 bits ou des op´ erateurs MAC de 18 bits. Au niveau inf´ erieur, les LABs sont constitu´ es de 8 ALM (Adaptive Logic Module) et d’un r´ eseau de connexions locales. Les ALMs, sch´ ematis´ es a ` la figure 29, sont r´ ealis´ es autour d’un bloc de logique combinatoire ` a 8 entr´ ees, de deux additionneurs et des registres de sortie. Le bloc combinatoire est en fait r´ ealis´ e avec deux LUTs a ` quatre entr´ ees et de quatre LUTs a ` trois entr´ ees.

Figure 1.3 – Niveau sup´ erieur de la hi´ erarchie de l’architecture du circuit Stratix II

1.4

Le processeur embarqu´ e NIOS

Le processeur embarqu´ e NIOS est un processeur a ` coeur logiciel de type firmcore , c’est a ` dire exclusivement d´ edi´ e` a la famille d’Altera. Le processeur NIOS peut ˆ etre associ´ e` a une large gamme de p´ eriph´ eriques, des instructions personnalis´ ees et des acc´ el´ erateurs pour cr´ eer un SoPC . Le coeur logiciel de processeur embarqu´ e NIOS est configurable et ´ evolutif, pour permettre aux int´ egrateurs syst` emes de disposer d’une solution SoPC souple et tr` es robuste. Ce processeur peut ˆ etre facilement combin´ e avec la logique d’utilisateur et ˆ etre programm´ e dans un FPGA.

5

Figure 1.4 – Syst` eme Altera NIOS La figure d´ ecrit le syst` eme NIOS. Il est constitu´ e du processeur NIOS, du bus Avalon et des p´ eriph´ eriques (contrˆ oleur m´ emoire, UART, timer. . . ). Le processeur NIOS est le coeur du syst` eme, il est connect´ e aux diff´ erents p´ eriph´ eriques ` a travers le bus Avalon. Ce bus doit ˆ etre configur´ e en maˆ ıtre/esclave. L’interface du bus Avalon est g´ en´ er´ ee automatiquement par l’outil de g´ en´ eration d’Altera NIOS (SOPC Builder).

1.4.1

Processeur NIOS

Le processeur NIOS est un processeur RISC enti` erement synchrone, son architecture interne de type Harvard. Il poss` ede au maximum 6 niveaux de pipeline 1 cadenc´ ea ` 50 MHz avec une largeur de bus de 32 bits. Ses performances sont de 30 ` a 80 MIPS (Million Instructions per Second). Il est possible d’acc´ el´ erer certains traitements, en ajoutant des instructions personnelles (d´ ecrites en VHDL) au processeur NIOS. De cette mani` ere, il est possible de r´ ealiser de la surcharge d’operateurs ou simplement d’´ etendre les jeux d’instruction. D’apr` es la figure 34, on voit bien qu’on peut ajouter a ` l’Unit´ e Arithm´ etique et Logique (UAL) du processeur NIOS essentiellement deux types d’instruction : combinatoire (un seul cycle) ou s´ equentiel (multi cycle) .
1. selon versions du NIOS II

6

Figure 1.5 – CPU NIOS

Figure 1.6 – Instruction personnalis´ ee du processeur NIOS II La soci´ et´ e Altera propose trois versions pour le processeur NIOS II. La table illustre ces trois versions. Une premi` ere version Economy qui utilise moins de surface, une deuxi` eme version Standard qui permet un compromis entre surface et rapidit´ e, une derni` ere version Fast qui est plus rapide que les deux autres. Pipeline Multiplication Mat´ eriel Branch Prediction Cache d’Instructions Cache de donn´ ees Instructions Personnalis´ es NIOS II /f 6 niveaux 1 Cycle Dynamic Configurable Configurable Sup´ erieur a ` 256 NIOS II /s 5 niveaux 3 Cycle Static Configurable Non Sup´ erieur a ` 256 NIOS II /e Non Par logiciel Non Non Non Sup´ erieur a ` 256

7

Figure 1.7 – Implantation du processeur NIOS II sur diff´ erents circuits FPGA d’Altera La figure ci-dessus repr´ esente les performances en DMIPS (Dhrystons Million Instructions per second, unit´ e issue du benchmark dit de Dhrystons) et la surface occup´ ee des diff´ erentes versions du NIOS II sur diff´ erentes familles de FPGA d’Altera (Stratix II, Stratix, Cyclone). D’apr` es 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 a ` un autre FPGA.

1.4.2

Bus Avalon

Le bus Avalon peut ˆ etre vu comme un ensemble de signaux pr´ ed´ efinis permettant de connecter un ou plusieurs IP. La figure 36 pr´ esente le bus Avalon. Ce bus comprend un d´ ecodeur d’adresse, un multiplexeur de donn´ ees, un g´ en´ erateur de cycles d’attente et un contrˆ oleur d’interruption. Les utilisateurs peuvent facilement int´ egrer leurs propres p´ eriph´ eriques avec le reste du syst` eme bas´ e 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´ ecessaire au partage d’une mˆ eme ressource partag´ ee par les circuits maˆ ıtres. Cette architecture multi maˆ ıtre fournit la grande flexibilit´ e dans la conception des syst` emes. Les figures repr´ esentent un exemple de d´ eroulement des cycles de lecture et d’´ ecriture (respectivement) sur le bus Avalon du syst` eme.

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´ esente les donn´ ees a ` lire readdata si le signal wait request est a ` “0 “. (D) : Le port maˆ ıtre capture les donn´ ees readdata sur le prochain front montant. Puis le transfert se termine et un autre cycle peut recommencer.

Figure 1.10 – Cycle d’´ ecriture 9

(A) : Le cycle d’´ ecriture 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 ` a “0” sur le front montant de clk, alors le transfert se termine et un autre cycle de lecture ou ´ ecriture peut recommencer.

10

Chapitre 2 ` CONCEPTION DU SYSTEME ´ ´ MULTIMEDIA EMBARQUE
2.1 Introduction

Durant la conception d’un SoC, le concepteur aura a ` choisir le composant programmable qui sera le coeur du syst` eme, la plupart des architectures sont bas´ ees sur des processeurs ` a usage g´ en´ eral. Ces processeurs sont extensibles du fait que beaucoup d’applications peuvent yˆ etre implant´ ees, tandis que les performances obtenues peuvent ˆ etre inf´ erieures a ` celles obtenues avec des processeurs d´ edi´ ees a ` des applications sp´ ecifiques. Mais l’approche de conception mixte logicielle/mat´ erielle permet ` a l’application d’atteindre des performances inaccessibles aux approches de conception classiques. Les r´ ealisations logicielles sont pr´ ef´ er´ ees pour des raisons d’´ evolution et de coˆ ut. Par contre, les r´ ealisations mat´ erielles sont d´ edi´ ees aux fonctionnalit´ es n´ ecessitant des circuits sp´ ecialis´ es ou des performances ´ elev´ ees.

Figure 2.1 – Conception traditionnelle et codesign Le codesign implique donc une conception en mˆ eme temps du mat´ eriel et du logiciel. La figure 41 illustre la diff´ erence entre la m´ ethodologie de conception traditionnelle et le codesign. En fait, dans la conception traditionnelle, la d´ efinition de l’architecture est suivie par le d´ ecoupage des tˆ aches qui vont ˆ etre r´ ealis´ ees par les ´ equipes du mat´ eriel et du logiciel. L’´ equipe du mat´ eriel r´ ealise une description du syst` eme en utilisant un langage de description mat´ eriel tel que le VHDL ou le Verilog. Puis elle r´ ealise la synth` ese et la g´ en´ eration des circuits int´ egr´ es en utilisant des outils de CAO. L’´ equipe du logiciel est responsable de l’´ ecriture du code qui 11

va ˆ etre compil´ e et ex´ ecut´ e sur des processeurs d’usage g´ en´ eral. Ensuite, les ´ equipes r´ ealisent l’int´ egration physique des deux parties. Mais, on constate que le manque d’interaction entre ces deux ´ equipes pendant les ´ etapes de d´ eveloppement peut g´ en´ erer plusieurs probl` emes d’int´ egration. Dans , il est rapport´ e que 71.5% des projets syst` eme embarqu´ e n’atteignent pas 30 % des performances attendues durant la phase de conception. Ces probl` emes peuvent ˆ etre ´ evit´ es par l’utilisation d’une m´ ethodologie de conception conjointe logicielle/mat´ erielle. En effet, les ´ equipes du logiciel et du mat´ eriel travaillent ensemble et a ` chaque ´ etape de conception, elles r´ ealisent l’int´ egration et le test des sp´ ecifications. Les op´ erations de test et d’int´ egration g´ en` erent une augmentation du temps de conception. L’int´ egration finale lors du prototypage est r´ ealis´ ee sans difficult´ e. On constate que la m´ ethodologie de conception conjointe r´ eduit le temps total de conception puisqu’elle r´ eduit le nombre de retours a ` des ´ etapes ant´ erieures de conception provoqu´ es par la d´ etection d’erreur.

2.2
2.2.1

Plateforme mat´ erielle de traitement vid´ eo
Introduction

Cette partie est consacr´ ea ` l’´ etude et a ` la conception d’une plateforme mat´ erielle d’acquisition, de traitement et de restitution vid´ eo servant de pr´ ealable a ` toute ´ etude d’algorithme de traitement vid´ eo. La plateforme mat´ erielle s’articule autour de la carte Cyclone II d’Altera compl´ et´ ee d’une interface cam´ era et d’une interface LCD 2”2. Le coeur du syst` eme met en oeuvre le module IP NIOS II d’Altera dans l’environnement de d´ eveloppement Quartus II d’Altera. Les modules IPs d’acquisition, restitution vid´ eo ainsi que des modules IPs de base n´ ecessaires (module PIO, I2C) ont ´ et´ e d´ evelopp´ es. des application en C ont ´ et´ e utilis´ e pour le contrˆ ole logiciel de la plateforme mat´ erielle. Enfin, l’ensemble des blocs IPs a servi ` a constituer une biblioth` eque.

2.2.2

Conception d’un syst` eme SoPC

Quartus II est un logiciel propos´ e par la soci´ et´ e Altera permettant la gestion compl` ete d’un flot de conception FPGA. La figure pr´ esente 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’architecture num´ erique, d’en r´ ealiser une simulation en utilisant le simulateur ModelSim de Mentor Graphics, une synth` ese et une implantation sur FPGA. Il comprend une suite de fonctions de conception au niveau syst` eme permettant d’acc´ eder ` a la large biblioth` eque d’IPs d’Altera et un moteur de placement/routage int´ egrant la technologie d’optimisation et des solutions de v´ erification. D’une mani` ere g´ en´ erale, un flot de conception ayant pour but la configuration de composants programmables se d´ eroulent de la mani` ere suivante

Figure 2.3 – Flot de conception 13

L’IDE (Integrated Design Entry) Quartus II int` egre l’outil SOPC Builder qui permet de construire un syst` eme SoPC int´ egrant divers p´ eriph´ eriques d’E/S tels que le processeur NIOS II, les contrˆ oleurs de SRAM et de SDRAM, un contrˆ oleur DMA (Direct Memory Access). . . De mˆ eme, on peut int´ egrer son propre composant dans le design sous forme d’un bloc IP externe (Interface cam´ era, LCD ,VGA. . . ). On peut ainsi int´ egrer autant de p´ eriph´ eriques que l’on veut, n’´ etant limit´ e que par le nombre de broches et de cellules logiques du circuit FPGA. Le mapping m´ emoire et le niveau des interruptions du design sont fix´ es durant cette phase. La figure montre la mise en oeuvre de l’outil SOPC Builder. C’est en fait la premi` ere passerelle avec le logiciel embarqu´ e.

Figure 2.4 – SOPC Builder et mapping m´ emoire A l’issue de la phase de construction du syst` eme SoPC, Quartus II g´ en` ere le projet en int´ egrant tous les modules IPs. Apr` es synth` ese, on a le fichier de programmation du circuit FPGA correspondant au design SoPC mais aussi un kit de d´ eveloppement logiciel qui comprend tous les fichiers en langage C (.h et .c) pour piloter les p´ eriph´ eriques d’E/S d’Altera. C’est en fait la deuxi` eme passerelle avec le logiciel embarqu´ e. L’offre de codesign apparaˆ ıt ici avec la possibilit´ e de d´ evelopper une partie de l’application par mat´ eriel ou de le faire en logiciel par langage C.

14

2.3

Platforme de d´ eveloppement : CycloneII FPGA Multimedia board

Plate-forme Cyclone II multim´ edia est un outil pour tout ce qu’il couches : D´ ebutant, pr´ einterm´ ediaire et avanc´ e. Ses modules compl´ ementaires fournissent la conjonction de l’´ ecole et les concepteurs de l’entreprise. L’utilisateur peut mettre en œuvre VLSI (Very Large Scale Int´ egration) ... avec DHL, la conception de circuit logique num´ erique et de r´ ealiser davantage l’ les m´ edias num´ eriques et le processeur d’image

Figure 2.5 – CycloneII FPGA Multimedia board

2.3.1

Caract´ eristique g´ en´ erale

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’` a la performance de la conception du syst` eme, de r´ eduire Clock Skew - Provid DSP Block, jusqu’` a ex´ ecution de l’op´ eration 2. Quatre s´ eries 384K byte Frame Buffer m´ emoire - Il peut donn´ ees d’image provisoires ` a 2,0 Panel ”LCD ou VGA 3. Deux s´ eries 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´ esolution (dot) : 320 (W) x240 (H) 5. Capteur d’image CMOS - 30ten milliers de pixels a ` la capture d’iamge actif / statique (fonction de mise au point) 6. Deux s´ eries de ports de sortie PS2 - Contrˆ ole du clavier et de la souris 15

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

Figure 2.6 – CycloneII FPGA Multim´ edia board multim´ edia composantes

16

2.4

Syst` eme d’acquisition et de traitement vid´ eo

Nous avons con¸ cu et r´ ealis´ e une plateforme mat´ erielle d’acquisition de traitement et de restitution vid´ eo servant a ` l’´ evaluation de notre m´ ethodologie de conception logicielle/mat´ erielle pour les syst` emes multim´ edia embarqu´ es . La figure repr´ esente notre plateforme.

Figure 2.7 – Notre syst` eme d’acquisition, traitement et restitution vid´ eo

2.5
2.5.1

Principe de base de traitement d’image
D´ efinition d’une image et des types d’images

Une image est stock´ ee en m´ emoire sous forme de collection de points ´ el´ ementaires appel´ es pixels. Nous pouvons consid´ erer une image num´ erique comme une page de nombres organis´ es en tableau ou en matrice. Chaque nombre repr´ esente les caract´ eristiques du pixel. La position de chaque pixel peut ˆ etre exprim´ ee par deux coordonn´ ees sur l’axe horizontal X et l’axe vertical Y comme le montre la figure ci-dessous.

Figure 2.8 – El´ ement d’une image : le pixel Le codage d’un pixel d´ epend du type d’image et nous en recensons trois types : 1. Les images a ` deux niveaux : une image en noir et blanc est l’exemple le plus courant. Toute image d´ ecrite avec deux valeurs correspond a ` ce type. Un bit suffira pour coder la valeur d’un pixel. 2. Les images ` a plusieurs niveaux de gris : les images de nos t´ el´ eviseurs en noir et blanc sont de ce type. La plupart des syst` emes d´ efinissent 256 niveaux de gris. Mais, seuls 128 niveaux de gris sont d´ etectables par l’oeil. 17

3. Les images couleurs : la couleur peut ˆ etre cod´ ee, soit par composition de couleurs primaires, soit par composition d’informations de luminance et de chrominance. En fait, une couleur peut ˆ etre repr´ esent´ ee par un ensemble de trois coordonn´ ees, c’est-` adire qu’une couleur peut ˆ etre reproduite par la superposition de trois couleurs primaires comme montre la figure 4. Le syst` eme RVB (Rouge-Vert-Bleu ou RGB ) utilise les couleurs primaires : rouge, vert et bleu. La valeur du pixel doit repr´ esenter les composantes trichromatiques de la couleur. En g´ en´ eral, nous disposons de huit bits pour coder une composante, soit 24 bits pour coder la valeur d’un pixel. Ce syst` eme RVB peut donc d´ efinir plus de 16 millions de couleurs. Des r´ esultats exp´ erimentaux ont prouv´ e que l’oeil est beaucoup plus sensible aux variations fines d’intensit´ e lumineuse (luminance) qu’` a celles de la couleur (chrominance). Il en r´ esulte que nous pouvons nous contenter de transmettre l’information de couleur avec moins de d´ etails 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 ˆ etre visuellement simul´ ee en convoluant le signal avec les fonctions de sensibilit´ e des trois diff´ erents capteurs r´ etiniens du syst` eme 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´ ehender les structures de l’image de la mˆ eme fa¸ con, engendrant diff´ erentes erreurs de reconstruction et par la mˆ eme, de fausses couleurs visuellement choquantes. On pr´ ef´ era donc un espace de luminance et chrominance rouge et bleu YCrCb (ou YUV) o` u les primaires sont d´ ecorr´ el´ ees, ce qui offre l’avantage de s´ eparer les informations d’intensit´ e lumineuse et de couleur. Un tel espace permet de g´ erer les premi` eres avec plus de soin. A titre d’exemple, voici la matrice de passage de l’espace RVB ` a l’espace YUV :

2.5.3

D´ efinition de la vid´ eo

La vid´ eo est une succession d’images anim´ ees. Le principe fondamental de la vid´ eo est que l’oeil humain a la possibilit´ e de retenir pendant un certain temps (de l’ordre du dixi` eme de seconde) toute image imprim´ ee sur la r´ etine. Il suffit donc de faire d´ efiler 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` emes vid´ eo : les syst` emes vid´ eo analogiques et les syst` emes vid´ eo num´ eriques. La vid´ eo analogique La cam´ era balaye l’image bidimensionnelle qu’elle a devant elle par un faisceau d’´ electrons qui se d´ eplace tr` es rapidement de gauche a ` droite et plus lentement de haut en bas et produit une tension en fonction du temps. Elle enregistre ainsi l’intensit´ e lumineuse, et ` a la fin du balayage, on a alors une trame. Le faisceau revient a ` l’origine pour recommencer. Le r´ ecepteur va recevoir cette intensit´ e en fonction du temps, et pour reconstruire l’image, va r´ ep´ eter le processus de balayage. Les param` etres pr´ ecis de ce balayage varient d’un pays a ` l’autre mais deux grandes familles existent : En Europe (syst` eme PAL/SECAM, pour Phase Alternating Line / SEquentiel Couleur Avec M´ emoire) ce syst` eme utilise 625 lignes (seulement 576 sont affich´ ees), un rapport vertical/horizontal de 4/3 et un d´ ebit de 25 images par seconde. En Am´ erique et au Japon (syst` eme NTSC, pour National Television Standards Committee), on a seulement 525 lignes (483 affich´ ees) et un d´ ebit de 30 images par seconde

Figure 2.10 – Principe de balayage utilis´ e pour la vid´ eo et la t´ el´ evision La vid´ eo num´ erique La vid´ eo num´ erique est tout simplement une suite d’images form´ ees d’une matrice de pixels. Pour obtenir des images en couleur, il faut utiliser au moins 8 bits par pixel, ce qui correspond a ` 256 couleurs. En fait, avec 8 bits par pixel, on obtient de la vid´ eo num´ erique noir et blanc de haute qualit´ e. Pour la vid´ eo num´ erique couleur, on utilise 8 bits pour chaque couleur RVB, soit donc 24 bits par pixel, ce qui correspond ` a environ 16,8 millions de couleurs. Le principe de balayage utilis´ e est similaire ` a celui de la vid´ eo analogique.

19

Chapitre 3 ´ ` REALISATION DU SYSTEME
Pour r´ ealis´ e notre syst` eme multim´ edia embarqu´ ee on se basons sur les fichiers HDL fournit par le constructeur de notre carte cible . Ces fichier HDL sont ´ ecrit en Verilog est ont d´ ecrit les deux interface de capteurs CMOS pour l’utilis´ e comme un slave de I2C : CMOS2BUFFER.v , et CMOSI2C.v et un troisi` eme fichier de contrˆ oler 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´ ees brutes peut ˆ etre manuelle cibl´ ee.

Figure 3.1 – inputs/ouputs de capteur CMOS afin d’avoir d´ emarrer le capteur camera il faut le configur´ e pour obtenir la sortie d´ esir´ e. 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` eme 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´ e La cam´ era sera charg´ ee bien entendu de capturer un flux d’image et devra ˆ etre configur´ ee pour fournir les donn´ ees sur 8 bits sous le format RGB qui est le plus facile a ` g´ erer.

Figure 3.3 – configuration du camera

21

3.2

Notre Syst` eme

pou mieux optimis´ e notre syst` eme on a choisit cette architecture dans la quelle le processeur NIOS II communique avec la camera (SDRAM) et l’LCD par l’interm´ ediaire des IP de PIO : parllele input output

Figure 3.4 – notre syst` eme NIOS les information image sont enregistr´ e dans les SRAM de 1Mo par les les entit´ es de CMOS et le sortie de notre syst` eme fournie l’image trait´ e a l’interface de l’LCD

22

Figure 3.5 – vue d’ensemble de notre syst` eme NIOS

3.3

cr´ eation de syst` eme sur quartus II et SoPC builder

afin de satisfait notre vision on utilisons SoPC builder pour cr´ ee le processeur NIOS et leurs p´ eriph´ eriques :

23

Figure 3.6 – le processeur NIOS et leurs p´ eriph´ eriques Apr` es avoir g´ en´ er´ e les IP on s’int´ eresse a ´ etablir la connexion entre les diff´ erentes composantes du syst` eme et les association des PIN avec les PIN r´ eel 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` eme et U24 pour la reset globale.

Figure 3.7 – le sch´ ema block de notre syst` eme

3.4

Le premier test : Hello World !

apr` es avoir t´ el´ echarg´ e le fichier .sof g´ en´ er´ e par la compilation de notre syst` eme , on passe a NIOS IDE pour commenc´ e` a programmer le NIOS II . 24

pour notre premier test on va seulement affich´ e “Hello world ! “ dans le consol NIOS , pour sela on cr´ e´ e un nouveau BSP projet dans NIOS IDE avec le fichier de configuration de notre SoPC . Deux projet sont cr´ ee le premier s´ e’est le projet qu’on va modifier le deuxi` eme est le projet contienne les fichier de drivers des diff´ erent composantes du SoPC ( PIO , RAM , JTAG ...)
1 2 3 4 5 6 7 8 9 10 11 12

#include <stdio.h> int main() { while(1) printf("Hello from ENSAK ! \ n");

return 0; } }

Figure 3.8 – Hello world dans le cadre de debugg´ e ce programme on rencontre plusieurs probl` eme : 1. le NIOS fast est n´ ecessite un licence pour l’utiliser un message d’erreur s’affiche si on essai de l’impl´ ement´ e sur la carte ,alors on se limite par NIOS/e 2. la m´ emoire ram de 40K peut ˆ etre satur´ e par des grand code , et les deux SDRAM dans la carte est d´ ej` a utilis´ e comme un buffer de camera

25

3.5
3.5.1

Programme de traitement d’image
L’algorithme

Seul un type de traitement a ´ et´ e´ etudi´ e et appliqu´ e sur l’image fournie par la cam´ era. Ce traitement consiste simplement a ` faire un seuillage sur une des 3 composantes d’un pixel. Pour ce faire, l’id´ ee est la suivante : on regarde si la somme des 3 composantes est inf´ erieure a ` 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 a ` 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 ´ ecrire dans un PIO ou lire d’apr´ e un autre IOWR ALTERA AVALON PIO DATA(x,BASE) cette fonction faire l’´ ecriture 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´ ementation du programme

cette algorithme simple , fait un bon choix pour mieux comprendre les outils de programmation de NIOS sans effort plus sur la complexit´ e de l’algorithme .
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

/* * FORCAGEb.c * * Created on: 17 juin 2013 Author: yAcine * */ #include <stdio.h> #include"system.h" #include "altera avalon pio regs.h" #define WRITE(x) (IOWR ALTERA AVALON PIO DATA(x,CAMERA BASE)) #define READ (IORD ALTERA AVALON PIO DATA(LCD BASE)) int main() { //RGB 8 bit unsigned char unsigned char unsigned char unsigned char

Color; R; G; B;

26

21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53

//printf("Hello from Nios II! \ n"); while(1) { if(READ=0x0) WRITE(0xFFFF); else { R=READ; delay ms(D); G=READ; delay ms(D); B=READ; delay ms(D); } if(3*B>R+G+B) { R=0; //0x0000 G=0; //0x0000 B=255; //0xFFFF } WRITE(R); delay ms(D); WRITE(G); delay ms(D); WRITE(B); delay ms(D);

} return 0; }

27

Conclusion
Au cours de cette ´ etude, on a pr´ esent´ e le d´ eveloppement d’une plateforme mat´ erielle d’acquisition et de restitution vid´ eo en Temps R´ eel en utilisant la conception mixte logicielle mat´ erielle. Cette plateforme se base sur la carte de d´ eveloppement Cyclone II d’Altera qui est connect´ ee a ` la carte d’interface cam´ era et a ` celle de l’interface LCD. Le cœur du syst` eme est le processeur embarqu´ e NIOS II d’Altera. Les modules IPs d’acquisition et de restitution vid´ eo ont ´ et´ e d´ evelopp´ es afin d’interfacer les deux modules externes avec la carte de d´ eveloppement. On a pu voir en outre que la mise en oeuvre d’un application avec NIOS IDE sur le processeur NIOS II pour assur´ e le traitemet d’image mais cette application reste insuffisant pour des application avanc´ e en terme de complexit´ e et en terme d’ordonnancement . Alors il est important d’impl´ ementer un syst` eme d’exploitation comme uClunix ,RT Linux,RTOS ou RTEMS

28