Projet Light

UE PBD
Plateform Based Design Master SESI
Plateform Based Design
PROJET LIGHT
EQUIPE TOURISTE
Conception d’un nœud de capteurs sans-fil pour

la surveillance des locaux du master SESI
Olivier ROMAIN 1
olivier.romain@upmc.fr
01 44 27 96 33
UE PBD
I. Introduction
1.1 Les réseaux de capteurs sans-fil
1.1.1. En quoi ça consiste?
Les capteurs sont des éléments essentiels dans tous les systèmes où les informations issues de
l'environnement extérieur sont nécessaires pour évoluer et agir. De ce fait, avoir une
connaissance précise et complète sur ce milieu exige le déploiement de plusieurs capteurs, et
si possible, conjuguer toutes les informations renvoyées pour mieux ajuster les paramètres de
chaque capteur. L'avancée remarquable dans le domaine des télécommunications a permis de
supprimer les liaisons filaires de transmission fort encombrantes. D'autant plus que les câbles
d'alimentations ne sont plus indispensables étant donné que la consommation de tels circuits
n'a cessé de baisser. Toutes ces fonctionnalités nous permettent d'imaginer un système
complexe construit autour de plusieurs capteurs en communication sans fils, capables de
s'adapter selon les évolutions rencontrées.
Un réseau de capteur est constitué d'un grand nombre d’unités (nœuds). Chaque nœud est
composé d'un ou plusieurs capteurs, d'une unité de traitement et module de communication.
Les unités d'un réseau dialoguent entres elles selon la topologie du réseau et l'existence ou pas
d'une infrastructure (points d'accès) afin d’acheminer les informations à une unité de
commande hors de la zone de mesure.
1.1.2. Les diverses réalisations pratiques
L'utilisation des capteurs en liaison sans fil devient une nécessité pour construire un système
dont la mobilité est une caractéristique dominante. On parle alors de capteurs embarqués sur
des unités mobiles, voir fixes repartis sur une surface considérable. Dans ce cas, la
transmission des acquisitions est plus aisée qu'avec l'utilisation d'une transmission filaire. Les
applications d'une telle architecture sont nombreuses dans différents domaines d’applications.
Elles dépendent étroitement de la catégorie des capteurs utilisés :
- Capteurs d’Image : caméra CCD ou rétine CMOS.

- Son : voix, vibration, …
- Positionnement : gyroscope, boussole électronique, GPS…
- Capteurs d’environnement : température, pression, radiation, …
Olivier ROMAIN 2
01 44 27 96 33
UE PBD
L'une des principales applications est la construction d'un réseau d'unités autonomes mobiles
capables de se déplacer dans des zones inconnues, inaccessibles ou hostiles à l'être humain.
On arrive ainsi à fournir des informations sur le terrain afin d'établir une stratégie d'évolution
selon le but souhaité. On peut par exemple localiser des victimes lors des opérations de
sauvetage, ceci est possible grâce à de petits mobiles capables de s'infiltrer à travers les
décombres ou d'autres plus étanches pour explorer les fonds aquatiques. Une autre application,
et non la moindre, est l'exploitation militaire. Dans ce contexte, l'emploi des réseaux de
capteurs peut aller des surveillances de routine des périmètres, jusqu'à assister des attaques
aériennes ou terrestres et de conduire des opérations d'espionnage.
Pour cela, il faut qu'aucun élément ne soit indispensable pour le fonctionnement du réseau.
Une telle architecture, dite en ad-hoc, permet de maintenir le réseau en action suite à la perte
d'un ou de plusieurs éléments.
Figure 1 : Routage de l'information dans un réseau ad-hoc
En effet, un réseau Ad-hoc ne nécessite pas une infrastructure préexistante, où chaque nœud
est capable de router l'information. Plusieurs autres applications sont possibles,
essentiellement pour des systèmes embarqués.
Olivier ROMAIN 3
01 44 27 96 33
UE PBD
Quelques domaines d'application:
- Environnement: Eau, forêt, animaux…

- Transport (MIT): Trafic, état des routes, …
- Spatial (Intel): Exploration de mars.
- Topologie de réseau.
Des laboratoires ont mis en œuvre des réalisations pratiques. Dans ce qui suit, quelques
applications sont citées en guise d'exemples et données en annexes :
 Université de Berkeley (USA) + Intel + DARPA

C'est un réseau constitué de 800 capteurs différents. Chaque élément du réseau est
constitué d'un capteur de température et un autre de lumière, une batterie, Module RF T1000,
10kb/s et un microprocesseur ATMEL Risc 8bits 4MHz + RTOS (TinyOs)
- Suisse (Institut fédéral des technologies)
Il s'agit d'une étude topologique d'un réseau Ad-Hoc. C'est un reseau de capteurs de
température dotés d'un module Ericsson pour la communication sans fil et un microprocesseur
RISC (8 bits, 4MHz et 128 Kbits de memoire flash.
- Université de Pennsylvanie (USA)

C'est un système pour contrôler la qualité des eaux.
Olivier ROMAIN 4
01 44 27 96 33
UE PBD
- Université de Pise (Italie)

Contrôle des parcs naturels : Gaz, feux, animaux, …
Présentation du Projet
• Spécifications
• Volet technique
• Annexe technique
Olivier ROMAIN 5
01 44 27 96 33
UE PBD
II. Spécifications
2.1 Introduction
L’objectif de ce projet consiste en la conception d’un réseau de capteur sans fil qui sera
déployé dans les locaux du Master SESI de l’Université Paris 6. Celui-ci permettra en temps
réel de mesurer la température afin de prévenir d’un éventuel incendie et de détecter des
mouvements au moyen d’un capteur d’image en technologie CMOS.
Ainsi par le biais de ce mini réseau, nous pouvons imaginer plusieurs scénarios comme par
exemple :
 Détecter un incendie par la mesure conjointe de la température et de l’image du feu.
 Réguler la température dans les salles en fonction de l’exposition solaire. En utilisant,

le réseau de capteur nous pourrons obtenir la cartographie thermique du des bâtiments
de l’entreprise, et ainsi optimiser le chauffage en plein hiver par exemple.
 Surveiller d’éventuel vol de matériel.
 Vérifier la présence des élèves dans la salle. Ainsi une feuille de présence est alors
créée automatiquement sans falsification.
 Etc.
2.2 Spécification de l’architecture du réseau de capteur

L’architecture du réseau de capteur sera composée à l’issu de ce projet de plusieurs unités de
mesures appelées balises et d’une unité de contrôle (voir Fig 1). Chaque balise envoie ses
informations à l’unité de contrôle au moyen d’une liaison sans fil.
L’unité de contrôle possède 3 fonctions élémentaires :
• Centraliser les informations de chaque balise en fonctionnement

• Afficher les paramètres de chaque salle mesurés par les balises
• Détecter les possibles scénarios présentés ci-dessus.
Olivier ROMAIN 6
01 44 27 96 33
UE PBD
Balise n°1 Balise n°2 Balise n°3
Salle 1 Salle 2 Salle 3
Salle 6 Salle 5 Salle 4
Tâche n°0. T
°
Tâche n°1. I
Balise n°5 Unité de Balise n°4 mage
contrôle
fig. 1: Architecture du réseau de capteurs sans fil
2.2.1. Description de la balise
La balise est composée de trois unités distinctes (figure 2).
Unité Unité de traitement Unité de

d’acquisition communication
Interface capteur
T°
Interface
µP
Zigbee
Vision
fig. 2 : Architecture interne de la balise
Unité d’acquisition
Le rôle de l’unité d’acquisition est d’obtenir des mesures numériques des paramètres
environnementaux des salles. Pour cela, l’unité d’acquisition est basée sur l’utilisation de trois
capteurs analogiques:
Olivier ROMAIN 7
01 44 27 96 33
UE PBD
• un capteur de température
• une caméra CMOS numérique
Le champ de vue d’une caméra étant restreint (<90°), toute la salle ne pourra alors être
acquise par ce capteur de vision. Afin d’étendre le champ de vue de la caméra, une monture
gyroscopique (azimut et élévation) commandé par deux servomoteurs seront utilisés. Le
déplacement de la caméra sera fait par l’unité de traitement suivant deux modes :
o Un mode automatique ou l’unité de traitement déplacera suivant un chemin de

positionnement prédéfini par l’utilisateur, la caméra.
o Un mode manuel ou la caméra sera déplacé par l’utilisateur au moyen d’un

joystick de type PS2.
Unité de traitement
L’unité de traitement est basée sur l’utilisation de la carte Altera Nios CycloneII. Celle-ci
utilise un FPGA de la famille des Cyclones ou un processeur de type Nios II y sera implanté.
Le rôle de l’unité de traitement est d’acquérir les informations en provenance de l’unité

d’acquisition de les traiter et de les envoyer à l’unité de radiocommunication afin que l’unité
de contrôle puisse les réceptionner correctement. Pour cela, le processeur Nios devra intégrer
deux interfaces.
Unité de radiocommunication
Pour réaliser notre réseau de capteurs sans fil, trois normes peuvent être utilisées, la norme
Bluetooth (IEEE802.15), la norme Wifi (IEEE802.11b) et la norme Zigbee (IEEE802.15.4).
Le choix entre ces deux normes dépend essentiellement de plusieurs caractéristiques comme
la consommation, la possibilité de réaliser des réseaux Ad-hoc, la simplicité d’interfaçage
avec la plate forme Altera.
Par rapport à l’application envisage, nous avons choisi d’utiliser la norme Zigbee au moyen
de module de radiocommunication de type Xbee Pro de la société Maxstream du fait des
avantages qu’il confère.
Olivier ROMAIN 8
01 44 27 96 33
UE PBD
fig. 3 : Module de radiocommunication de type Xbee pro
2.2.2. L’unité de contrôle
L’unité de contrôle est basée sur l’utilisation d’un PC ou interface de radiocommunication est
adjointe. Cette interface sera la même que celle qui sera utilisée dans les balises. La liaison
utilisée entre le PC et le module de radiocommunication sera de type série (RS232) comme le
montre la figure 4 ci-dessous :
RS232 Zigbee
fig. 4 : Architecture de l’unité de contrôle
2.3 Organisation du projet

Le projet sera organisé de la manière suivante :
 Des équipes de 4 personnes seront formées avec un responsable. Le responsable de

l’équipe aura en charges d’organiser, de gérer et de coordonner les différentes tâches à
réaliser pour mener à bien ce projet. Il sera l’interface permanente avec l’encadrant.
 Chaque équipe devra réaliser conformément au cahier des charges :

o Une balise
o Une unité de contrôle (si le temps le permet)
 Chaque équipe devra suivre une méthodologie de type cycle en V comme suit :
Olivier ROMAIN 9
01 44 27 96 33
UE PBD
Expression des Maintenance

besoins
Spécifications Validations
Conception Tests
générale Intégration
Conception Tests
détaillée Unitaires
Réalisation
 Le volume horaire alloué est de 6 séances de 4h00 le mardi après-midi de 13h30 à

17h30.
Tâche n°0. Un encadrant sera là pour vous débloquer lorsque vous estimerez être
désespéré !
Tâche n°1. L’évaluation sera faite sur quatre critères :

a. Qualité du travail
i. Autonomie, travail en équipe, management, produit fini, etc.
b. Rapport de projet
i. Clarté, orthographe, grammaire, synthèse et possibilité d’être reprit par
une tierce personne, etc.
c. Présentations
i. Clarté, expression orale, qualité des slides, organisation des slides, etc.
d. Démonstration
i. Opérationnelle en fin de projet.
III. Volet technique

3.1 Fonctionnalités de la balise
Chaque balise possédera les propriétés fonctionnelles suivantes.
Olivier ROMAIN 10
01 44 27 96 33
UE PBD
3.1.1. Acquisition des données
Les spécifications des capteurs présentés dans le paragraphe sur l’architecture détaillée de la
balise sont données en annexe. Les capteurs permettent de mesurer localement des paramètres
physiques.
3.1.2. Traitement des données
Les mesures numériques de température devront être corrigées. Un traitement de celles-ci

devra être fait afin de les rendre exploitable avant leurs émissions. Les traitements seront
réalisés en langage C pour le Nios.
L’image acquise par la caméra correspondra à une image de luminance. L’image sera
monochromatique avec des pixels codés sur 8 bits (256 niveaux de gris).
3.1.3. Enregistrement des données pour un suivi temporel
On souhaite pouvoir avoir un historique des données acquises. Lorsque l’unité de contrôle
enverra un ordre de type « historique requis » la balise devra être capable de lui envoyer les
données acquises (température) toutes les minutes pendant une journée.
3.1.4. Affichage local des données
Afin de contrôler les valeurs acquises par la balise avant leurs émissions à l’unité de contrôle,
on souhaite que la balise possède un écran LCD ou les orientations (azimut et élévation) de la
caméra seront affichées. D’autre part, l’unité de contrôle est pourvue de deux afficheurs 7
segments ou le mesure de la température locale sera affichée.
Avant d’envoyer une image à l’unité de contrôle, on souhaite avoir un suivi local. Pour cela,
l’unité de contrôle sera pourvue d’une interface VGA. Celle-ci sera capable d’envoyer sur un
moniteur d’ordinateur, l’image acquise en temps réel.
3.1.5. Emission des données à l’unité de contrôle
La balise devra avant d’émettre ses données, rechercher l’unité de contrôle à laquelle elle
appartient (recherche par identifiant), assurer la non rupture de la communication établie et
assurer le dialogue avec l’unité de contrôle. L’émission des données sera faite par
l’intermédiaire d’un module Bluetooth décrit ci-dessus et en annexe. Son interfaçage avec
l’unité de traitement de la balise devra être fait.
3.1.6. Outils de conception HW et SW
Pour la conception matérielle de la balise et de l’unité de contrôle, les outils suivants seront
utilisés :
Olivier ROMAIN 11
01 44 27 96 33
UE PBD
• Quartus II
• SOPC Builder
• SignalTap Analyzer II
• Analyseur logic USB (à demander à l’encadrant)
Pour la conception logicielle de la balise, les outils suivants seront utilisés :

• Langage C
• Eclipse IDE Nios II
3.2 Architecture détaillée de la balise

L’architecture détaillée de la balise que vous allez concevoir est donnée ci-dessous. Elle
s’articule autour du processeur Nios II implémenté dans un FPGA. Plusieurs interfaces sont
utilisées, afin de connecter les périphériques au processeur (UART, Bus Avalon, PIO, …).
Ces interfaces sont soit directement disponible dans les MegaCores d’Altera, soit ce sont des
périphériques que vous aurez conçu.
IP
Contrôleur
PPM
Servomoteurs
Pan / Tilt
Bus Avalon
Module
U Zigbee
Interface
Caméra Bus
Nios II A
Avalon R
T
Interface
VGA P Affichage
Bus I Température
Avalon
O
IP IP
Contrôleur Contrôleur
PS2 SMT160
Capteur de
température
Olivier ROMAIN 12
01 44 27 96 33
UE PBD
3.3 Fonctionnalités de l’unité de contrôle

Chaque unité de contrôle devra posséder les fonctionnalités décrites ci-dessous.
3.3.1. Réception des données émises
Une unité de contrôle devra pouvoir dialoguer avec une balise spécifique mais aussi avec
l’ensemble de celles qui seront présentes. Pour cela, l’unité de contrôle sera pourvue d’une
interface de communication basée sur le même module Zigbee que les balises. Vous devrez
développer cette interface. Un programme en langage C devra être de plus développer afin de
piloter l’interface conçue.
3.3.2. Affichage des données émises
L’unité de contrôle sera pourvue d’une interface graphique afin d’afficher les données
acquises par une balise spécifique. Sur l’ordre d’un opérateur, une évolution graphique des
paramètres devra être faite. Dans sa version finale, l’interface graphique devra permettre
d’afficher l’ensemble des balises présentes et d’afficher les paramètres d’une balise choisie.
3.4 Organisation du projet

Afin de mener à bien la conception de la balise et de l’unité de commande, l’ensemble du
projet peut être découpé en plusieurs tâches qui sont détaillées dans le document. Chaque
tâche est indépendante et peut être menée par une ou plusieurs personnes d’une même équipe.
Le découpage donné est à titre indicatif. Il n’y a aucune obligation de le suivre. Par contre, il
conviendra d’argumenter la stratégie choisie à la fois dans le rapport et lors de la soutenance
du projet.
Tâche n°0. Prise en main de l’environnement de développement QUARTUS

a. Prise en main de Quartus
b. Applications : développement d’IP
c. Compte rendu
Tâche n°1. IP Contrôleur de température

a. Conception de l’IP Contrôleur SMT160
b. Tests et validation
Olivier ROMAIN 13
01 44 27 96 33
UE PBD
c. Compte rendu
Tâche n°2. Processeur Nios II

a. Conception du système à base du processeur Nios
b. Gestion de la balise par le Nios
c. Compte rendu
Tâche n°3. Déplacement de la caméra

a. Conception de l’IP contrôleur des servomoteurs
b. Gestion par le Nios II
c. Compte-rendu
Olivier ROMAIN 14
01 44 27 96 33
UE PBD
TÂCHE N°0
Prise en main de l’environnement de développement Quartus

Application à la conception d’IP
Objectif :
L’objectif de cette première séance est de se familiariser avec les outils de conception Quartus.
Vous allez apprendre dans ce TP un flow de conception top-down, c'est-à-dire de la
spécification à la synthèse de composants décrits en VHDL, en passant par la simulation.
Pour cela, cette séance portera sur la conception de plusieurs IP, des registres, ALU, filtre de
type FIR et une UART basée à base de FSM. La difficulté des exercices est croissante.
I. Prise en main de Quartus II

1.1 Conception d’un nouveau Projet
Généralement, un système électronique est composé de plusieurs composants. Chaque

composant est décrit, compilé et simulé indépendamment des autres avant d’être relié aux
autres. Pour cela, il est nécessaire de créer un projet.
Lancer Quartus II dans le menu Démarrer\Altera\Quartus II si vous êtes dans un

environnement Windows, sinon, lancer un terminal et aller dans le répertoire Altera pour
trouver l’exécutable. La fenêtre suivante apparaît :
Olivier ROMAIN 15
01 44 27 96 33
UE PBD
Allez dans le menu File et lancer New Project Wizard. Cet assistant va vous guidez pas à pas
pour créer votre projet.
Sous Quartus II, les projets sont liés à des cibles matériels (FPGA ou CPLD). La principale
raison provient du fait que les simulations sont post-synthèse par défaut.
Vous allez créer un répertoire tache0 et vous nommerez votre premier projet, tache0. La
famille de FPGA que vous sélectionnerez sera la famille Cyclone avec le circuit
correspondant à la carte que vous utiliserez. Demander à ce niveau à l’encadrant. Les autres
options seront celles par défaut. Une fois terminé, appuyer sur Finish.
Vous pouvez alors observer dans la fenêtre Project Navigator la composition de votre projet
(entité de haut niveau et circuit utilisé).
Olivier ROMAIN 16
01 44 27 96 33
UE PBD
Edition et compilation
Une fois le projet crée, il est possible d’y insérer plusieurs fichiers de description de
composants : des descriptions structurelles à l’aide de fichier BDF (Block Diagram File) ou
des descriptions comportementales à l’aide de fichier VHDL, AHDL ou Verilog.
Description comportementale
Sélectionner dans le menu File, la commande New. La fenêtre suivante apparaît.
Olivier ROMAIN 17
01 44 27 96 33
UE PBD
Une fenêtre, éditeur de fichier Vhd1.vhd apparaît. Avant de commencer à écrire votre code,
enregistré le fichier. Attention le nom du fichier correspond au nom que vous donnerez à
votre entité.
Ecrivez le code VHDL d’une bascule D.
Description structurelle
Dans le menu File\New, sélectionner Block Diagram/Schematic File. Une fenêtre vierge
apparaît. Enregistrer votre fichier.
Quartus II vous offre toute une librairie de composant décrit en VHDL que vous pouvez vous
servir. Pour cela, appuyer sur le bouton Symbol Tool matérialisé par le symbole d’une porte
ET.
Olivier ROMAIN 18
01 44 27 96 33
UE PBD
Une nouvelle fenêtre apparaît. Prenez le composant Bascule D (dff) et intégré le sur votre
feuille vierge.
Afin de pouvoir être simulé, il est alors nécessaire d’adjoindre à la bascule des entrées/sorties
physiques, broches.
Pour cela, sélectionner dans la fenêtre symbole, les composants input et output. Reliez les
entrées/sorties du composant avec des fils (signaux 1 bit correspond au bouton « wire »).
Enregistrer votre fichier.
Utiliser les composants disponibles pour réaliser un registre à décalage à gauche de 4 bits.
Compilation
Avant de simuler un circuit, il est nécessaire de vérifier qu’il ne comporte pas d’erreur de
conception. Pour cela nous allons le compiler. Si votre projet comporte plusieurs descriptions,
le compilateur par défaut synthétisera l’entité de haut niveau, celle qui correspond à la
description de tout le système.
Olivier ROMAIN 19
01 44 27 96 33
UE PBD
Dans l’onglet Files du Project Navigator sélectionner le fichier que vous voulez compiler.
Appuyer sur le clic droit de la souris et sélectionner Set as Top-Level Entity. En réalisant
cette opération le compilateur ne synthétisera que ce composant.
Aller dans le menu Tools et appuyer sur Compiler Tool. Une nouvelle fenêtre apparaît.
Lancer le compilateur. Le compilateur analyse, synthèse et réalise un placement routage du
composant sur le circuit cible. L’ensemble des rapports de compilation et d’analyse des
performances sont disponibles à partir de cette fenêtre (compiler tool).
Simulation
Cette étape consiste à vérifier le comportement du composant crée. Attention, cette étape
nécessite d’avoir compiler au préalablement le circuit.
Dans le menu File\New, sélectionner l’onglet Other files et Vector Waveform Files. Ce
fichier permet de décrire visuellement le testbench que vous allez utiliser pour tester votre
circuit.
Olivier ROMAIN 20
01 44 27 96 33
UE PBD
Enregistrez le fichier sous Bench_nom du composant. Par exemple pour la basculeD, le nom
du test bench sera Bench_BasculeD.vwf.
Le fichier de simulation est divisé en deux parties. Une colonne pour le les broches d’entrées /
sorties du composants et une zone graphique munie d’une échelle temporelle. Dans la colonne
Name, à l’aide d’un clic droit de la souris, lancez la commande Insert a node or bus, puis
l’outil Node Finder. Cet outil permet de récupérer les noms des entrées/sorties du composant
que vous avez créé.
Sélectionner les signaux, clk, D et Q. et terminer l’opération.
D et clk sont des entrées. Nous pouvons leur affecter des valeurs manuellement ou utiliser des
stimulis prédéfinis. Pour le signal clk, dans la barre d’outils Waveform Editor sélectionnez
overwrite clock. Prenez une période d’horloge par défaut à 10ns. Pour le signal D, vous
prendrez un compteur qui s’incrémente tous les 50 ns. Enregistrer votre fichier.
Nous allons simuler le comportement du circuit avec le test_bench que vous venez de réaliser.
Pour cela, dans le menu Tools, sélectionnez Simulator Tool. A l’aide du navigateur,
recherchez votre fichier de simulation et lancez la simulation. Le résultat de la simulation
apparaît.
Olivier ROMAIN 21
01 44 27 96 33
UE PBD
Programmation de la carte
Une fois la conception du système terminé et dans le cas ou le comportement en simulation

respecte les spécifications du cahier des charges, Quartus II permet de programmer une carte
pour vérifier le système sur un circuit. Pour cela, dans le menu Tools, sélectionner
Programmer. Nous ne ferrons pas cette étape ici mais nous l’approfondirons ultérieurement.
II. Applications
Maintenant que vous maîtrisez l’environnement de développement, c’est à vous de jouer !
2.1 Registre et Additionneur
2.1.1 Registre sur n bits
Définir de façon comportementale un registre de taille variable sur n bits comportant un reset
synchrone.
• Compilez le registre et observer les résultats de la compilation.
• En déduire la fréquence maximale d’utilisation de ce composant ?
• Combien de ressource prend ce composant dans le FPGA ?
• Simulez le composant avec n égal à 4 pour une horloge d’une période de 10 ns et 10µs.
• Déterminer un fichier de simulation Waveform Vector file afin d’observer les résultats
sous Quartus.
• Comparer les résultats obtenus
2.1.2 Additionneur sur n bits
Définir de façon comportementale un additionneur ayant en entrée deux opérandes a et b sur n

bits et en sortie un résultat y sur n bits.
• Compilez le composant conçu et observer les résultats de la compilation
• Simulez le composant avec n égal à 4, mesurer le temps nécessaire afin d’avoir le

résultat en sortie.
Olivier ROMAIN 22
01 44 27 96 33
UE PBD
• Que se passe-t-il si on veut additionner les nombres 15 et 7 ?
2.2 Application à l’étude d’un premier Filtre FIR

Dans cette partie, on désire réaliser un filtre possédant l’équation suivante :
y(n) = x(n) + x(n-1)
x(n) est un échantillon de l’entrée x à l’instant n et x(n-1) est un échantillon du signal x à

l’instant (n-1). Les deux sont codées sur 16 bits.
• Définir de manière comportementale ce filtre caractérisé par une architecture pipeline.
• Définir de manière structurelle ce filtre, avec une architecture pipeliné, en utilisant les
composants décrits dans la partie 1.
• Testez le bon fonctionnement de cette architecture en la simulant.
• Déterminer la fréquence d’horloge minimale pour l’architecture décrite
2.3 Conception d’un filtre réalisant une moyenne sur n échantillons
Dans cette partie, on désire réaliser un filtre possédant l’équation suivante :
y(n) = x(n) + x(n-1) + x(n-2) + x(n-3) + …+ x(0)
x(n) est un échantillon de l’entrée x à l’instant n et x(n-1) est un échantillon du signal x à

l’instant (n-1). Les deux sont codées sur 16 bits.
• Définir une architecture pour ce filtre. La solution retenue sera explicitée.
• Testez le bon fonctionnement de cette architecture en la simulant.
• Déterminer la fréquence d’horloge minimale pour l’architecture décrite
2.4 Conception d’une IP de type contrôleur UART
On se propose de synthétiser un circuit d’émissionde données en mode asynchrone type start-

stop. Chaque caractére est défini par un start bit, 8 bits de données et un stop bit. Le schema
de principe est donnée par la figure 1.
Olivier ROMAIN 23
01 44 27 96 33
UE PBD
Figure 1 : Système d’émission
Les caractéristiques du circuit d’émission sont les suivantes :
• Les entrées d’horloge de tous les circuits sont actives sur un front descendent
• Le registre à décalage 8 bits est chargé en parallèle par la donnée à transmettre D7…D0
• Les signaux de contrôle du registre à décalage sont :
o SI : entrée série
o SO : sortie série
o MC : entrée de contrôle de Mode
 MC = 0 décalage a droite
 MC = 1 chargement parallèle
o CLK : horloge pour le décalage
• Le signal d’horloge TxCLK est obtenu par la division par 16 d’une horloge qui est aussi
utilisée par le circuit de réception série
• Les entrées Set et Reset de la bascule D sont asynchrones
• Le circuit de contrôle et la bascule sont initialisés par Reset
Olivier ROMAIN 24
01 44 27 96 33
UE PBD
• La commande Tx provoque la transmission série de l’octet D7…D0

• La sortie Zéro du détecteur de Zéro passe au niveau haut lorsque toutes ses entrées sont
à zéro
• Le circuit de contrôle est notamment constitué par une Machine à États dont les sorties
sont synchrones. La commande de Reset est synchrone.
• Le vecteur d’entrée est composé des signaux Zéro est Start
• Le vecteur de sortie est composé des signaux MODE SEND DATA et Ti
• Le signal SHIFT est le signal d’horloge appliqué sur la bascule D et sur l’entrée CLK du
registre a décalage
• Les chronogrammes des différents signaux, correspondant à l‘émission d’un octet, sont
tracés sur la Figure 2.
Figure 2 : chronogramme
1. Décrivez en VHDL un registre 8 bits à chargement parallèle et à décalage

2. Décrivez en VHDL le détecteur de zéro
3. Réalisez le diagramme de transition de la machine à états à l’aide du chronogramme de la
Figure 2
4. À l’aide des outils Mentor, décrivez la machine à états
5. À l’aide d’un schéma structurel assemblez le tout, vous utiliserez les composants fournis
par le logiciel pour ce qui est le portes logique Et, Ou et bascule D avec RS
6. Ecrivez en VHDL les stimuli de test du circuit d’émission
7. Testez votre composant
8. Synthétiser sur cible FPGA ALTERA Cyclone en essayant différentes périodes d’horloge
Olivier ROMAIN 25
01 44 27 96 33
UE PBD
Compte-rendu
Le compte rendu consiste dans la prise en main du sujet, il ne doit pas seulement se limiter a
l'écriture du code VHDL, mais plutôt a une analyse des questions, a une explication du code
VHDL écrit, avec vos commentaires ainsi que vos résultats de simulations. A la fin de chaque
partie de la séance il faudra faire valider l’exercice par un des deux enseignants responsables.
Olivier ROMAIN 26
01 44 27 96 33
UE PBD
TÂCHE N°1
Conception d’une IP de type contrôleur pour le capteur de
température SMT160-30
I. Introduction : Présentation d’un capteur de température

Le SMT160-30 est un capteur de température intégré à trois bornes, doté d'un signal de sortie
caractérisé par son rapport cyclique (Duty Cycle). Deux des bornes sont utilisées pour
l'alimentation en 5V et la troisième pour le signal de sortie. Le résultat de la mesure est
présent à la sortie sous forme de rapport cyclique et peut faire l'objet d'un échantillonnage par
un microprocesseur. Par ailleurs l'information reste disponible sous forme analogique. Aucun
convertisseur Analogique Numérique ou interface spéciale n'est nécessaire.
Le SMT160-30 permet de mesurer la température avec une précision absolue de 0.7 °C dans
l'intervalle -30 °C à +100 °C et 1.2 °C de -45°C à +130 °C. Cela rend le capteur très utile dans
toutes les applications où des conditions "humaines" (contrôle de climat, transformation des
produits alimentaires etc.) doivent être contrôlées. La sortie du capteur, de technologie CMOS,
peut être déportée par un câble jusqu'à 20 mètres. Ceci rend le SMT160-30 très utile dans des
applications de télédétection et de commande. Vous pourrez trouver la documentation
complète sur le site du constructeur SMARTEC à l’adresse http://www.smartec.fr
II. Description fonctionnelle

La sortie du capteur est compatible avec les microcontrôleurs et peut être reliée directement
à la plupart des processeurs. En mesurant numériquement (par échantillonnage) T1 et T2
(voir l'image du signal de sortie ci-dessus), la température se calcule facilement à l'aide de la
formule suivante:
Olivier ROMAIN 27
01 44 27 96 33
UE PBD
On peut par ailleurs obtenir la valeur de la température en mesurant le signal de sortie à l'aide
d'un système analogique. La tension moyenne (ainsi que la valeur RMS) est directement
proportionnelle au rapport cyclique (Duty Cycle) et à la tension d'alimentation. Par
conséquence Vout /Vdd représente également la valeur de T1/T2.
En définitive la température peut être mesurée d'une manière simple et précise, aussi bien de
façon analogique que numérique.
III. Travail à réaliser
On désire réaliser une IP d’un contrôleur SMT160 qui servira d’interface entre le capteur de
température et le micro processeur de type Nios. Cette IP permettra d’obtenir une valeur
numérique de la température à partir du Nios. Pour cela, dans un premier temps nous
réaliserons une IP qui sera interfacée au Nios par le bais d’un port d’entrée/sortie de type PIO
puis dans un second temps nous l’intégrerons directement au Nios en l’interfaçant au bus
avalon.
3.1 Conception de l’IP SMT160 version PIO

L’entité à développer en VHDL devra être conforme aux spécifications données ci-dessous :
IP contrôleur
clk data_out[N..0]
reset
mesure
L’IP devra comporter en entrée :

• un signal data_in : sortie du capteur de température
• un signal de reset :
• une horloge système à 50 MHz
L’IP devra comporter en sortie :
Olivier ROMAIN 28
01 44 27 96 33
UE PBD
• un signal data_out : sur n bits (à vous de définir) correspondant à la valeur numérique

de la température
3.1.1 Développement de l’IP SMT160-30
Vous êtes libre de concevoir cette IP comme vous le souhaité. C'est-à-dire, soit de manière
comportementale ou structurelle.
3.1.2 Simulation et validation
Effectuer les simulations du contrôleur.
3.2 Extension de l’IP SMT160 version bus Avalon
Il existe deux manières de connecter une IP au processeur Nios, soit en utilisant un port
d’entrée / sortie (PIO cf : synoptique du démonstrateur et cours), soit en utilisant le bus
Avalon. Dans cette partie, nous allons modifier l’IP conçue auparavant afin que son interface
prenne en compte les signaux disponibles sur le bus avalon.
IP contrôleur
clk data_out[31..0]
reset
adress[1..0]
cs
rd
mesure
data_in [31..0]
wr
• un signal d’adresse sur 2 bits, qui permettra d’accéder aux registres de l’IP
o address = 0x01 : registre d’horloge / échantillonnage
o address = 0x10 : registre d’état de l’IP
Olivier ROMAIN 29
01 44 27 96 33
UE PBD
• un signal data_in sur 32 bits : bus de donnée Avalon

• un signal mesure : sortie du capteur de température
• un signal cs : sélection du périphérique sur le bus Avalon
• un signal wr : signal d’autorisation d’écriture dans les registres de l’IP
• un signal rd : signal d’autorisation de lecture dans les registres de l’IP
• un signal de reset : remise à zéro des registres
• une horloge système

• un signal data_out sur 32 bits, qui permettra de récupérer les données acquises sur le
bus avalon
3.2.1 Développement de l’IP
Apporter à la première version de l’IP les modifications nécessaires afin qu’elle prenne en
compte les signaux disponibles sur le bus avalon. Les spécifications des signaux disponibles
sur les bus sont données dans la documentation de chez Alera (AN : Bus Avalon).
3.2.2 Simulation et validation
Effectuer les simulations du contrôleur sous l’environnement que vous souhaitez, soit
Modelsim ou soit Quartus.
IV. Compte rendu

Consigner dans votre compte rendu, les résultats que vous avez obtenus pour cette partie.
Vous mettrez en annexe de votre compte rendu les différents programmes que vous avez
développés ainsi que la méthodologie que vous avez adopté.
Fin tâche n°1
Olivier ROMAIN 30
01 44 27 96 33
UE PBD
TÂCHE N°2
Conception du système Nios 2
I. Introduction :
Dans cette partie, nous allons nous intéresser à concevoir une IP de type micro processeur
Nios 32 bits en utilisant l’outil SOPC Builder. L’entité Nios (I ou II) devra prendre en compte
les ressources de la carte de développement mais aussi les différentes interfaces (IP) qui
seront développées dans le cadre des tâches 1, 3, 4 et 5.
II. Conception matérielle

2.1 Concevoir et définir les différentes interfaces que le Nios doit intégrer afin qu’il puisse
avoir accès aux ressources de la carte de développement (SDRAM, SRAM, Led, Bouttons,
etc.). Pour cela nous utiliserons l’outil SOPC Builder. (Manuel de conception HW en annexe).
2.2 En fonction de l’avancement des autres tâches, intégrer dans le Nios 2 les IP SMT160, IP
PPM et IP PS2.
2.3 Compiler et synthétiser le système
2.4 Programmer la carte
III. Conception logicielle

Dans cette partie, nous allons utiliser les outils GNU (compilateur, linker et debugger) afin de
développer un programme en C qui permettra au processeur Nios de mesurer au travers de
l’IP la valeur de la température et d’afficher sur l’écran LCD l’orientation de la caméra
3.1 Développer un programme en C qui permettra de valider le fonctionnement du processeur

Nios2 développé.
3.2 En fonction des IPs développées dans les autres tâches, réalisé un programme en C qui
permettra :
• L’affichage sur les afficheurs 7 segments de la valeur de la température acquise
• De gérer le déplacement de la caméra suivant deux modes :
o Automatique
o Manuel : souris PS2
Olivier ROMAIN 31
01 44 27 96 33
UE PBD
• De récupérer l’information de mouvement issus du traitement de la caméra
IV. Tests et validation
4.1 Connecter l’interface qui vous sera remise sur la carte ALTERA
4.2 Tester et valider pratiquement le comportement de votre balise
VI. Compte Rendu

développés.
Fin tâche n°2
Olivier ROMAIN 32
01 44 27 96 33
UE PBD
TÂCHE N°3
Conception d’une IP de type contrôleur PPM en VHDL pour le
déplacement de la monture gyroscopique de la caméra
I. Introduction : Présentation d’un servomoteur

Un servomoteur est un dispositif typiquement utilisé en modélisme pour, par exemple,
contrôler la direction d'une voiture
télécommandée.
Il comprend :
• Un moteur électrique (continu),

généralement assez petit.
• Une réduction en sortie de ce moteur pour
avoir moins de vitesse et plus de puissance.
• Un capteur : un potentiomètre qui induit
une résistance variable en fonction de
l'angle de l'axe de sortie.
• Un asservissement électronique pour
contrôler la position de cet axe de sortie.
L'utilisateur envoie à chaque instant un signal

modulé qui représente un angle.
Le servomoteur tourne vers cet angle et s'y
maintient.
Commande d’un servomoteur
Un servomoteur s’interface avec un organe de commande à l’aide de trois fils (rouge, noir et
de couleur). Le rouge correspond à l’alimentation +5v (généralement), la masse (le fils noir)
et le signal de commande. Il est normalement blanc, mais il peut être jaune suivant le
fabriquant.
On pourrait penser qu'il faut fournir un PWM comme signal de commande au servomoteur
pour qu’il tourne comme pour un moteur à courant continu, mais ce n’est pas le cas. On utilise
généralement un signal de commande que l’on appelle PPM. La différence entre ces deux
commandes quasi similaire est explicitée ci-dessous :
Olivier ROMAIN 33
01 44 27 96 33
UE PBD
1. Le PWM (Pulse Width Modulation, Modulation en largeur d'impulsion) est un signal

dont le taux de modulation varie de 0 à 100% (TM=Ton/Tperiode) à fréquence fixe.
2. Pour un servomoteur on parle de PPM (Signal modulé en largeur d’impulsion) où
seule la largeur de l'impulsion compte indépendamment de la fréquence (en théorie).
Plus précisément, il faut fournir au servomoteur une impulsion à 1 (suivie d'un retour à 0).
Ainsi le servomoteur va prendre en compte la largeur temporelle de cette impulsion, qu'il va
convertir proportionnellement (ou presque) en un angle.
Le retour à 0 de l'impulsion peut avoir n'importe quelle durée. En pratique, il semblerait qu'il
ne faille pas dépasser un temps de 20ms entre deux fronts montants. A noter aussi que ce
système présente un avantage par rapport au PWM : une absence de signal (toujours à 1, ou
toujours à 0) laisse le servomoteur en "roue libre" comme si il n'était pas alimenté.
Les figures ci-dessous montrent les différences qu’ils existent entre une commande PWM
classique et une commande PPM utilisée par les servomoteurs.
figure 1 : Commande de type PWM
figure 2 : Commande de type PPM
Olivier ROMAIN 34
01 44 27 96 33
UE PBD
Valeurs typiques :
Dans la pratique, ont trouve généralement les valeurs suivantes :
• Milieu vers 1.44 ms

• -70 deg vers 0.8 ms
• -102 deg (butée) vers 0.51 ms
• +55 deg vers 1.92 ms
• +98.8 deg (butée) vers 2.31 ms
Soit un "pas" de 8µs correspond à 0.89 deg. Ou dans l'autre sens, un degré correspond à 9µs
approximativement. Une étape de calibrage sera nécessaire afin d’ajuster la largeur de
l’impulsion et ainsi d’obtenir une pleine échelle (de -90° à +90°).
Attention, les chronogrammes donnés ci-dessus ainsi que les valeurs sont des exemples. Les
valeurs temporelles dépendent du servomoteur que vous utiliserez. Il sera nécessaire de
réaliser une phase de calibration, par le biais d’un GBF (Générateur Basse Fonction),
préliminaire pour déterminer les valeurs temporelles à respecter.
II. Travail à réaliser

2.2.1 Développement HW
On désire réaliser une IP d’un contrôleur PPM qui servira d’interface entre le servomoteur et
le micro processeur de type Nios II. Cette IP permettra de faire tourner la caméra à partir du
Nios II. Pour cela, l’IP que nous allons concevoir sera directement intégré au Nios II par le
biais du bus avalon.
Olivier ROMAIN 35
01 44 27 96 33
UE PBD

• un signal data sur 32 bits, qui permettra d’envoyer des données dans les registres
(réglage de l’horloge, rapport cyclique, …)
• un signal d’adresse sur 2 bits, qui permettra d’accéder aux registres de l’IP
o address = 0x00 : registre de contrôle de l’IP
 Bit0 : reset de l’IP
 Bit1 : sortie active
o address = 0x01 : registre d’horloge
o address = 0x10 : registre rapport cyclique
o address = 0x11 : registre de calibration
 Bit0 : positionne le rapport cyclique à 25% quelque soit le rapport
cyclique programmé. Moins prioritaire que le Bit1.
cyclique programmé. Moins prioritaire que le Bit2.
cyclique programmé
• un signal cs : sélection du périphérique
• un signal wr : écriture dans les registres
• un signal de reset : remise à zéro des registres et du signal PPM
• une horloge système à 50 MHz

• Le signal de commande PPM
Après avoir développer l’IP, effectuer les simulations du contrôleur. Vérifier le comportement
voulu et consigner vos résultats dans votre compte-rendu.
2.2.2 Développement SW
Après avoir intégré l’IP dans le système Nios 2 (si la tâche correspondante a été réalisée),
développé sous l’environnement Eclipse le logiciel qui permet de déplacer le servomoteur.
Connecter la carte pour le servomoteur et vérifier le comportement du servomoteur.
III. Compte rendu

développés ainsi que la méthodologie que vous avez adopté.
Olivier ROMAIN 36
01 44 27 96 33
UE PBD
Fin tâche n°3
Olivier ROMAIN 37
01 44 27 96 33
UE PBD
Olivier ROMAIN 38
01 44 27 96 33

Projet Light

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Projet Light

Uploaded by

Copyright:

Available Formats

UE PBD

Plateform Based Design Master SESI

Plateform Based Design

Conception d’un nœud de capteurs sans-fil pour

1.1.2. Les diverses réalisations pratiques

- Capteurs d’Image : caméra CCD ou rétine CMOS.

Figure 1 : Routage de l'information dans un réseau ad-hoc

Quelques domaines d'application:

- Environnement: Eau, forêt, animaux…

 Université de Berkeley (USA) + Intel + DARPA

- Suisse (Institut fédéral des technologies)

- Université de Pennsylvanie (USA)

- Université de Pise (Italie)

 Réguler la température dans les salles en fonction de l’exposition solaire. En utilisant,

 Surveiller d’éventuel vol de matériel.

2.2 Spécification de l’architecture du réseau de capteur

L’unité de contrôle possède 3 fonctions élémentaires :

• Centraliser les informations de chaque balise en fonctionnement

Balise n°1 Balise n°2 Balise n°3

Salle 1 Salle 2 Salle 3

Salle 6 Salle 5 Salle 4

fig. 1: Architecture du réseau de capteurs sans fil

2.2.1. Description de la balise

La balise est composée de trois unités distinctes (figure 2).

Unité Unité de traitement Unité de

fig. 2 : Architecture interne de la balise

o Un mode automatique ou l’unité de traitement déplacera suivant un chemin de

o Un mode manuel ou la caméra sera déplacé par l’utilisateur au moyen d’un

Le rôle de l’unité de traitement est d’acquérir les informations en provenance de l’unité

fig. 3 : Module de radiocommunication de type Xbee pro

2.2.2. L’unité de contrôle

fig. 4 : Architecture de l’unité de contrôle

2.3 Organisation du projet

 Des équipes de 4 personnes seront formées avec un responsable. Le responsable de

 Chaque équipe devra réaliser conformément au cahier des charges :

Expression des Maintenance

 Le volume horaire alloué est de 6 séances de 4h00 le mardi après-midi de 13h30 à

Tâche n°1. L’évaluation sera faite sur quatre critères :

III. Volet technique

3.1.1. Acquisition des données

3.1.2. Traitement des données

Les mesures numériques de température devront être corrigées. Un traitement de celles-ci

3.1.3. Enregistrement des données pour un suivi temporel

3.1.4. Affichage local des données

3.1.5. Emission des données à l’unité de contrôle

3.1.6. Outils de conception HW et SW

Pour la conception logicielle de la balise, les outils suivants seront utilisés :

3.2 Architecture détaillée de la balise

3.3 Fonctionnalités de l’unité de contrôle

3.3.1. Réception des données émises

3.3.2. Affichage des données émises

3.4 Organisation du projet

Tâche n°0. Prise en main de l’environnement de développement QUARTUS

Tâche n°1. IP Contrôleur de température

Tâche n°2. Processeur Nios II

Tâche n°3. Déplacement de la caméra

Prise en main de l’environnement de développement Quartus

I. Prise en main de Quartus II

Généralement, un système électronique est composé de plusieurs composants. Chaque

Lancer Quartus II dans le menu Démarrer\Altera\Quartus II si vous êtes dans un

Sélectionner dans le menu File, la commande New. La fenêtre suivante apparaît.

Sélectionner les signaux, clk, D et Q. et terminer l’opération.

Une fois la conception du système terminé et dans le cas ou le comportement en simulation

2.1 Registre et Additionneur