Wiki d'activités IMA - Contributions de l’utilisateur [fr]

Projets IMA5 2014/2015

2015-02-24T11:16:30Z

Jvaessen : /* Répartition des binômes */

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en allant modifier le format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

== Répartition des binômes ==

<table border="1">
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<th>Rapports finaux</th>
<tr>
<td>[[P1 Modélisation et commande de l'auto-ignition d'un moteur HCCI]]</td>
<td>Moulé Alexandre / Taché Clément </td>
<td> Anne-Lise Gehin / Jean-Yves Dieulot </td>
<td>[[Fichier:Rapport decembre moule tache.pdf]] </td>
<td>[[Fichier: RapportFinPFE.pdf]]</td>
</tr>
<tr><td>[[P5 Filtrage des indicateurs numériques de diagnostic]]</td>
<td> ZIOU Ismaïl / HAMZAOUI Oussama </td>
<td> Belkacem Ould Bouamama </td>
<td>[[Fichier:rapport_Z.pdf]]</td>
<td>[[Fichier:Rapport PFE ZIOU HAMZAOUI.pdf]]</td>
</tr>
<tr>
<td>[[P6 Gestion des flux thermiques du bâtiment Polytech]]</td>
<td>Florian Royer / Zohour Assaieb </td>
<td> Belkacem Ould Bouamama </td>
<td> [[Fichier:Rapport_Intermédiaire_Royer_Assaieb.pdf]] </td>
<td> [[Fichier:Rapport_Final_PFE_ProjetP6.pdf]] </td>
</tr>
<tr><td>[[P7 Utilisation d'un Robot Nao pour les enfants autistes]]</td>
<td> Rodriguez Loïc/Ismaïl Tahry</td>
<td> GAPAS/Laurent Grisoni </td>
<td>[[Fichier:Projetpfenaomi.pdf]]</td>
<td>[[Fichier:Rapport PFE RodriguezTahry.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P8 Pilulier]]</td>
<td> Alexandre Mercier / Emile Pinet</td>
<td> Thomas VANTROYS / Alexandre BOE </td>
<td>[[Fichier:Rapport decembre PFE pilulier mercier pinet.pdf]]</td>
<td>[[Fichier:Rapport PFE Pinet Mercier.pdf]]</td>
</tr>
<tr><td>[[P9 Agenda pour personnes non lectrices]]</td>
<td> Cédric DESPREZ & Soufiane HADDAOUI </td>
<td> GAPAS/Laurent Grisoni </td>
<td>[[Fichier:Rapport_MiSoutenance_DESPREZ_HADDAOUI.pdf]]</td>
<td>[[Fichier:RapportFinal_Desprez-Haddaoui.pdf‎]]</td>
</tr>
<tr><td>[[P11 Détecteur d'obstacles pour fauteuils électriques]]</td>
<td> Geoffrey ROSE / Marjorie TIXIER </td>
<td> GAPAS / Blaise Conrard </td>
<td> [[Fichier:Rapport_Intermédiaire_PFE_GAPAS_Rose_Tixier.pdf]]
<td></td>
</tr>
<tr><td>[[P12 Automatiser à l'aide d'une interface LabView la procédure de mesure de conductivité électrique d'un alternateur à griffes]]</td>
<td> Hugo FONDU </td>
<td> Abdelkader Benabou </td>
<td>[[Fichier:rapport_presoutenance.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P13 Construction d'un support motorisé pour la réalisation des essais de décharges électrostatique]]</td>
<td> JEBBARI Zineb / BEKRAOUI Oumaima </td>
<td> Nathalie Rolland </td>
<td> [[Fichier:rapportJebbek.pdf]] </td>
<td> [[Fichier:rapport-final-jebbek.pdf]] </td>
<td></td>
</tr>
<tr><td>[[P19 Contrôle et synchronisation d'instruments en microscopie]]</td>
<td> Simon Duthoit</td>
<td> Samuel Hym </td>
<td></td>
<td>[[Fichier:RapportPFESimonDuthoit.pdf]]</td>
</tr>
<tr><td>[[P21 Balise Bluetooth Low Energy]]</td>
<td> Kévin CHALONO / Armagan YAMNAZ</td>
<td> Thomas VANTROYS </td>
<td> [[ Fichier:ProjetBLE 1 pdf.pdf]]</td>
<td>[[Fichier:Rapport_PFE_Yanmaz_Chalono2.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P21 Bis Prototypage d'interactions localisées et contextualisées ]]</td>
<td> Olivier Tailliez</td>
<td> Thomas Vantroys / Yvan Peter </td>
<td></td>
<td>[[Fichier: PFE_Olivier_Tailliez.pdf‎]]</td>
</tr>
<tr><td>[[P22 Google Glass en logistique ]]</td>
<td> Jérémy Gondry / Vincent Meunier </td>
<td> Laurent Grisoni </td>
<td>[[Fichier:Rapport_intermediaire_Gondry_Meunier.pdf]]</td>
<td>[[Fichier:Rapport_final_PFE_Meunier_Gondry.pdf]]</td>
</tr>
<tr><td>[[P24 Robot de surveillance domestique]]</td>
<td> Sébastien DELTOMBE </td>
<td> Xavier Redon </td>
<td>[[Fichier:Rapport_PFE_P24_Deltombe.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P25 SmartMeter]]</td>
<td> Thomas Ederlé / Sylvain Fossaert</td>
<td> Guillaume Renault / Xavier Redon / Alexandre Boé </td>
<td> [[Fichier:RapportFossaertEderle.pdf]] </td>
<td> [[Fichier:RapportEderleFossaert.pdf]] </td>
<td></td>
</tr>
<tr><td>[[P26 Vehicule Electrique ]]</td>
<td> Smain Labdouni / Adnane Jaoui </td>
<td> Arnaud Chielens / Philippe Delarue </td>
<td> [[Fichier:RAPPORT_VE_DEC.pdf]]</td>
<td> [[Fichier:Rapport_pfe_Jaoui_Labdouni_Fevrier.pdf]] </td>
</tr>
<tr><td>[[P27 Controle Direct de Puissance d'un Convertisseur Matriciel ]]</td>
<td> Quentin Pesqueux / Nicolas Alexandre </td>
<td> Philippe Delarue </td>
<td> [[Fichier:PFE_IMA5_MATRIX_CONVERTER_Alexandre_Pesqueux.pdf]]</td>
<td> [[Fichier:Rapport_PFE_Alexandre_Pesqueux.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle]]</td>
<td> Charlotte BRICOUT / Nathan MARTIN </td>
<td> Jérémie DEQUIDT</td>
<td> [[Fichier:-BRICOUT MARTIN--Rapport PFE.pdf]] </td>
<td></td>
</tr>
<tr><td>[[P33 Ligthing contactless / "wireless"]]</td>
<td> Benjamin Lafit </td>
<td> Alexandre Boé </td>
<td> [[Fichier:Rapport_Benjamin_Lafit.pdf]] </td>
<td> [[Fichier:Rapport_Final_Benjamin_Lafit.pdf‎]]</td>
<td></td>
</tr>
<tr><td>[[P35 Hack-a-Wii : Emulation de wiimote pour rendre la Wii accessibles aux personnes handicapées ]]</td>
<td> Fabien Violier </td>
<td> Laurent Grisoni </td>
<td> </td>
<td></td>
</tr>
<tr><td>[[P37 Creation d'un composant d'audit des accès cache mémoire sur un microprocesseur LEON3 simulé en FPGA ]]</td>
<td> Jérôme Vaessen </td>
<td> Julien Cartigny / Pierrick Buret </td>
<td> [[Fichier:Rapport_VAESSEN_presoutenance.pdf‎]] </td>
<td> [[Fichier:Rapport_PFE_P37_VAESSEN_finale.pdf‎]] </td>
<td></td>
</tr>
<tr><td>[[P44 Création d'un systeme domotique sans fil ]]</td>
<td> Benoit MALIAR / Thomas MAURICE</td>
<td> Pierrick BURET / Thomas VANTROYS </td>
<td> [[Fichier:RapportMaliarMauriceDecembre.pdf]] </td>
<td> [[Fichier:Rapport_final_Maliar_Maurice.pdf]]</td>
</tr>
<tr><td>[[P45 Aide à la navigation d'un véhicule autonome]]</td>
<td> Pierre APPERCÉ</td>
<td> Rochdi MERZOUKI </td>
<td></td>
<td></td>
</tr>
<tr><td>[[P46 Simulation Temps Réel d'un Environnement de Robots Autonomes Logisticiens]]</td>
<td> Valentin VERGEZ</td>
<td> Rochdi MERZOUKI </td>
<td></td>
<td></td>
</tr>
<tr><td>[[P57 CHRU Lille : Smart Picking]]</td>
<td> Mathieu Bossennec / Florian Caron</td>
<td> Gwénaëlle Maton / Alexandre Boé / Thomas Vantroys </td>
<td></td>
<td></td>
</tr>
<tr>
<td>[[P58 Transformation des spectateurs d’un concert en afficheur géant interactif]]</td>
<td> Hautecoeur Mélanie </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td>[[Fichier : PFE_Rapport_Hautecoeur_Melanie.pdf‎]]</td>
</tr>
<tr><td>[[P59 Assistance globale pour aide au parking]]</td>
<td> Mathieu GERIER / Céline LY </td>
<td> Alexandre BOE / Thomas VANTROYS </td>
<td>[[Fichier:Rapport_projet_intermediaire_GERIER_LY.pdf]]‎</td>
<td>[[Fichier:Rapport_projet_GERIER_LY.pdf]]</td>
</tr>
</table>

Projets IMA5 2014/2015

2015-02-24T11:14:55Z

Jvaessen : /* Répartition des binômes */

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en allant modifier le format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

== Répartition des binômes ==

<table border="1">
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<th>Rapports finaux</th>
<tr>
<td>[[P1 Modélisation et commande de l'auto-ignition d'un moteur HCCI]]</td>
<td>Moulé Alexandre / Taché Clément </td>
<td> Anne-Lise Gehin / Jean-Yves Dieulot </td>
<td>[[Fichier:Rapport decembre moule tache.pdf]] </td>
<td>[[Fichier: RapportFinPFE.pdf]]</td>
</tr>
<tr><td>[[P5 Filtrage des indicateurs numériques de diagnostic]]</td>
<td> ZIOU Ismaïl / HAMZAOUI Oussama </td>
<td> Belkacem Ould Bouamama </td>
<td>[[Fichier:rapport_Z.pdf]]</td>
<td>[[Fichier:Rapport PFE ZIOU HAMZAOUI.pdf]]</td>
</tr>
<tr>
<td>[[P6 Gestion des flux thermiques du bâtiment Polytech]]</td>
<td>Florian Royer / Zohour Assaieb </td>
<td> Belkacem Ould Bouamama </td>
<td> [[Fichier:Rapport_Intermédiaire_Royer_Assaieb.pdf]] </td>
<td> [[Fichier:Rapport_Final_PFE_ProjetP6.pdf]] </td>
</tr>
<tr><td>[[P7 Utilisation d'un Robot Nao pour les enfants autistes]]</td>
<td> Rodriguez Loïc/Ismaïl Tahry</td>
<td> GAPAS/Laurent Grisoni </td>
<td>[[Fichier:Projetpfenaomi.pdf]]</td>
<td>[[Fichier:Rapport PFE RodriguezTahry.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P8 Pilulier]]</td>
<td> Alexandre Mercier / Emile Pinet</td>
<td> Thomas VANTROYS / Alexandre BOE </td>
<td>[[Fichier:Rapport decembre PFE pilulier mercier pinet.pdf]]</td>
<td>[[Fichier:Rapport PFE Pinet Mercier.pdf]]</td>
</tr>
<tr><td>[[P9 Agenda pour personnes non lectrices]]</td>
<td> Cédric DESPREZ & Soufiane HADDAOUI </td>
<td> GAPAS/Laurent Grisoni </td>
<td>[[Fichier:Rapport_MiSoutenance_DESPREZ_HADDAOUI.pdf]]</td>
<td>[[Fichier:RapportFinal_Desprez-Haddaoui.pdf‎]]</td>
</tr>
<tr><td>[[P11 Détecteur d'obstacles pour fauteuils électriques]]</td>
<td> Geoffrey ROSE / Marjorie TIXIER </td>
<td> GAPAS / Blaise Conrard </td>
<td> [[Fichier:Rapport_Intermédiaire_PFE_GAPAS_Rose_Tixier.pdf]]
<td></td>
</tr>
<tr><td>[[P12 Automatiser à l'aide d'une interface LabView la procédure de mesure de conductivité électrique d'un alternateur à griffes]]</td>
<td> Hugo FONDU </td>
<td> Abdelkader Benabou </td>
<td>[[Fichier:rapport_presoutenance.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P13 Construction d'un support motorisé pour la réalisation des essais de décharges électrostatique]]</td>
<td> JEBBARI Zineb / BEKRAOUI Oumaima </td>
<td> Nathalie Rolland </td>
<td> [[Fichier:rapportJebbek.pdf]] </td>
<td> [[Fichier:rapport-final-jebbek.pdf]] </td>
<td></td>
</tr>
<tr><td>[[P19 Contrôle et synchronisation d'instruments en microscopie]]</td>
<td> Simon Duthoit</td>
<td> Samuel Hym </td>
<td></td>
<td>[[Fichier:RapportPFESimonDuthoit.pdf]]</td>
</tr>
<tr><td>[[P21 Balise Bluetooth Low Energy]]</td>
<td> Kévin CHALONO / Armagan YAMNAZ</td>
<td> Thomas VANTROYS </td>
<td> [[ Fichier:ProjetBLE 1 pdf.pdf]]</td>
<td>[[Fichier:Rapport_PFE_Yanmaz_Chalono2.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P21 Bis Prototypage d'interactions localisées et contextualisées ]]</td>
<td> Olivier Tailliez</td>
<td> Thomas Vantroys / Yvan Peter </td>
<td></td>
<td>[[Fichier: PFE_Olivier_Tailliez.pdf‎]]</td>
</tr>
<tr><td>[[P22 Google Glass en logistique ]]</td>
<td> Jérémy Gondry / Vincent Meunier </td>
<td> Laurent Grisoni </td>
<td>[[Fichier:Rapport_intermediaire_Gondry_Meunier.pdf]]</td>
<td>[[Fichier:Rapport_final_PFE_Meunier_Gondry.pdf]]</td>
</tr>
<tr><td>[[P24 Robot de surveillance domestique]]</td>
<td> Sébastien DELTOMBE </td>
<td> Xavier Redon </td>
<td>[[Fichier:Rapport_PFE_P24_Deltombe.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P25 SmartMeter]]</td>
<td> Thomas Ederlé / Sylvain Fossaert</td>
<td> Guillaume Renault / Xavier Redon / Alexandre Boé </td>
<td> [[Fichier:RapportFossaertEderle.pdf]] </td>
<td> [[Fichier:RapportEderleFossaert.pdf]] </td>
<td></td>
</tr>
<tr><td>[[P26 Vehicule Electrique ]]</td>
<td> Smain Labdouni / Adnane Jaoui </td>
<td> Arnaud Chielens / Philippe Delarue </td>
<td> [[Fichier:RAPPORT_VE_DEC.pdf]]</td>
<td> [[Fichier:Rapport_pfe_Jaoui_Labdouni_Fevrier.pdf]] </td>
</tr>
<tr><td>[[P27 Controle Direct de Puissance d'un Convertisseur Matriciel ]]</td>
<td> Quentin Pesqueux / Nicolas Alexandre </td>
<td> Philippe Delarue </td>
<td> [[Fichier:PFE_IMA5_MATRIX_CONVERTER_Alexandre_Pesqueux.pdf]]</td>
<td> [[Fichier:Rapport_PFE_Alexandre_Pesqueux.pdf]]</td>
<td></td>
</tr>
<tr><td>[[P28 Modélisation d'un robot chirurgical déformable pour la simulation et le contrôle]]</td>
<td> Charlotte BRICOUT / Nathan MARTIN </td>
<td> Jérémie DEQUIDT</td>
<td> [[Fichier:-BRICOUT MARTIN--Rapport PFE.pdf]] </td>
<td></td>
</tr>
<tr><td>[[P33 Ligthing contactless / "wireless"]]</td>
<td> Benjamin Lafit </td>
<td> Alexandre Boé </td>
<td> [[Fichier:Rapport_Benjamin_Lafit.pdf]] </td>
<td> [[Fichier:Rapport_Final_Benjamin_Lafit.pdf‎]]</td>
<td></td>
</tr>
<tr><td>[[P35 Hack-a-Wii : Emulation de wiimote pour rendre la Wii accessibles aux personnes handicapées ]]</td>
<td> Fabien Violier </td>
<td> Laurent Grisoni </td>
<td> </td>
<td></td>
</tr>
<tr><td>[[P37 Creation d'un composant d'audit des accès cache mémoire sur un microprocesseur LEON3 simulé en FPGA ]]</td>
<td> Jérôme Vaessen </td>
<td> Julien Cartigny / Pierrick Buret </td>
<td> [[Fichier:Rapport_PFE_P37_VAESSEN_finale.pdf‎]] </td>
<td></td>
</tr>
<tr><td>[[P44 Création d'un systeme domotique sans fil ]]</td>
<td> Benoit MALIAR / Thomas MAURICE</td>
<td> Pierrick BURET / Thomas VANTROYS </td>
<td> [[Fichier:RapportMaliarMauriceDecembre.pdf]] </td>
<td> [[Fichier:Rapport_final_Maliar_Maurice.pdf]]</td>
</tr>
<tr><td>[[P45 Aide à la navigation d'un véhicule autonome]]</td>
<td> Pierre APPERCÉ</td>
<td> Rochdi MERZOUKI </td>
<td></td>
<td></td>
</tr>
<tr><td>[[P46 Simulation Temps Réel d'un Environnement de Robots Autonomes Logisticiens]]</td>
<td> Valentin VERGEZ</td>
<td> Rochdi MERZOUKI </td>
<td></td>
<td></td>
</tr>
<tr><td>[[P57 CHRU Lille : Smart Picking]]</td>
<td> Mathieu Bossennec / Florian Caron</td>
<td> Gwénaëlle Maton / Alexandre Boé / Thomas Vantroys </td>
<td></td>
<td></td>
</tr>
<tr>
<td>[[P58 Transformation des spectateurs d’un concert en afficheur géant interactif]]</td>
<td> Hautecoeur Mélanie </td>
<td> Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td>[[Fichier : PFE_Rapport_Hautecoeur_Melanie.pdf‎]]</td>
</tr>
<tr><td>[[P59 Assistance globale pour aide au parking]]</td>
<td> Mathieu GERIER / Céline LY </td>
<td> Alexandre BOE / Thomas VANTROYS </td>
<td>[[Fichier:Rapport_projet_intermediaire_GERIER_LY.pdf]]‎</td>
<td>[[Fichier:Rapport_projet_GERIER_LY.pdf]]</td>
</tr>
</table>

Fichier:Rapport PFE P37 VAESSEN finale.pdf

2015-02-24T11:14:21Z

Jvaessen :

P37 Creation d'un composant d'audit des accès cache mémoire sur un microprocesseur LEON3 simulé en FPGA

2015-02-18T15:03:41Z

Jvaessen : /* Semaine 20: */

= Rapport de Présoutenance =

http://projets-imasc.plil.net/mediawiki/images/0/05/Rapport_VAESSEN_presoutenance.pdf

= Presentation du projet =

Ce projet s'inscrit dans l'amélioration d'une solution d'IP pour un SoftCore implanté dans un FPGA.

== Cahier des charges ==

Il faudra créer un composant VHDL capable de:

1.
sniffer les paquets à destination de la SDRAM/RAM (via le memory controler)

2.
Vérifier le contenu du paquet savoir, le type d'accès (lecture/écriture) de la mémoire

3.
compter le nombre d'accès mémoire en écriture

4.
Différencier les zones mémoires qui sont accéder afin de déterminer l'application/taches qui est à l'origine.

Il faudra aussi, faire cohabiter deux (ou plus) SoftCore Leon3 communicants sur le même bus AMBA.

== Planning: ==

=== Semaine 1: ===
Décourverte de l'équipe et discussion concernant le projet

=== Semaine 2: ===
Mise en place des outils (cygwin64 avec "développement") et discussion concernant les possibilités offertes concernant le bus AMBA

=== Semaine 3: ===
Après plusieurs essais d'utilisation des paquets tcl/tk fournis avec cygwin, nous nous sommes aperçus que l'environnement cygwin ne semble pas utilisable pour le projet.
C'est pour cela que nous passons à une autre solution ie Msys cependant nous sommes en train de faire en sorte d'avoir la bonne version des outils TCL/TK.

=== Semaine 4: ===
Mise en place d'un SoftCore Leon3 sur un FPGA, exploration des modifications à apporter afin d'implémenter deux softcores avec un cache L2C.

=== Semaine 5: ===

Mise en place de multiple SoftCore Leon3 sur un FPGA, exploration des modifications à apporter afin d'implémenter deux softcores avec un cache L2C.

=== Semaine 6: ===

Abandon du cache L2C (composant manquant).

Compilation d'un "hello world" avec les outils et paramètres adéquats pour une architecture multicoeur.

Épluchage des documentations afin d'établir les signaux pertinents pour réaliser des compteurs qui auront les caractéristiques suivantes:

-une paire de compteurs pour la lecture et l'écriture en mémoire

-3 paire de compteur (PROM, RAM et SDRAM).

=== Semaine 7: ===

Étude du composant contrôleur mémoire afin d'y implanter le composant. Cela nous permettra d'accéder facilement aux signaux pertinents pour le contrôle du composant. On fera en sorte d'avoir une sortie sur un GPIO.

=== Semaine 8: ===

Au lieu d'essayer de comprendre comment fonctionne de manière précise l'abritrage du bus amba et comment fontionne le processus de selection d'un composant en fonction de l'adresse sur le bus, je me suis concentré sur les signaux reliées directement au mémoire (ram, rom et sdram) physique afin d'écrire mon composant.

L'idée serait d'utiliser ces signaux et faire une sortie sur un GPIO pour connaitre son état en le visualisant sur un oscilloscope.

=== Semaine 9: ===

Discussion et abandon de l'idée de la semaine 8, car une nouvelle contrainte a été fixée:

-le résultat de chacun des compteurs devra pouvoir être accessible à des adresses mémoire sur le bus amba donc accessible par le processeur.

=== Semaine 10: ===

Mise au propre du cahier des charges, et étude de la norme AMBA.

Test grmon RCP au travers Eclipse, infructueux, car la carte n'est pas reconnue.

== Semaine 11: ==

Écriture d'une ébauche de composant et étude des possibilités en fonction des signaux disponible dans le contrôleur mémoire.

== Semaine 12: ==

Étude bibliographique (documents de Gaisler, norme AMBA).

== Semaine 13: ==

Rédaction du rapport et préparation à la présoutenance.

== Semaine 14: ==

Prise en main de ModelSim PE 10.4, pour simuler le SOC (des erreurs sont encore à régler).

== Semaine 15: ==

Début de l'écriture du composant:
- correction des incohérences du design (au niveau du déclenchement du composant)
- amélioration du design (réduction de largeur des bus)

== Semaine 16: ==

Écriture et test du composant.

== Semaine 17: ==

Écriture de la fonction de la reconnaissance d'écriture dans un composant surveillé.

Écriture de la fonction permettant la reprogrammation du composant en valeur maximale.

Documentation sur l'utilitaire Chipscope Pro et son utilisation avec la carte.

== Semaine 18: ==

Tentative d'utilisation de Chipscope Pro, des erreurs sont constatées (ce qui est d'ailleurs évoqué lors de la configuration dans Chipscope : "connection to PAD or IBUFG net can cause error in PAR") (Qui provoque des erreurs lors de l'implémentation du design).

On rajoute des bascules D afin d'éviter ces erreurs, cependant nous ne verrons que l'état des bus au moment des fronts montants ou descendants (ce que est logique, car l'on ne peut pas échantillonné avec durée inférieur à celle de l'horloge).

L'implémentation avec est impossible à cause d'un signal "non existent", alors que celui existe belle et bien, donc on peut confirmer le fonctionnement du composant grâce à la simulation.

Test des commandes utiles au travers de grmon pour la version non modifiée et modifié du leon3.

On a commencé la réflexion sur un cache l2c primitif, ce composant permettrais de fournir directement le résultat si celui-ci à déjà était réalisé auparavant (Analogie: une personne que pose deux fois de suite la même question dans un intervalle borné relativement court).

== Semaine 19: ==

Début du rapport final.

Raccourcissement du code du composant.

Écriture des signaux de sortie: hrdata, hresp et hready, des fonctions de multiplexage en sortie seront nécessaires.

Ceci reste à confirmer grâce à un test sur la carte et/ou une simulation.

Nous avons réussi à faire fonctionner la simulation sur Modelsim PE.

Nous avons fait en sorte que le composant soit visible et reconnu lors de la simulation*

*à confirmer sans les attributes keep

== Semaine 20: ==

Réalisé:

Le composant est présent dans le log de la simulation modelsim pe. Nous n'avons pas confirmé par la simulation du design, en effet on cherche une "solution simple" pour montrer son bon fonctionnement.

Reconnaissance du composant par le contrôleur de bus AMBA, on trouve une trace cohérente dans la mémoire à l'adresse 0xFFFFF800 (via grmon) est faite sur le design réelle (la carte).

Lecture de la valeur du compteur dans grmon (sur la carte), cela-ci s'incrémente en permanence (le compteur est régler pour s'incrémenter à chaque accés au contrôleur mémoire), il faut montrez qu'il est possible de surveiller une portion de la mémoire.

à faire:

Début de la présentation de PFE à faire.

Et rédaction du rapport à terminer.

Vidéo à faire.

-confirmer la présence du composant avec son compteur dans ModelSim PE
:Utile ?

== Annexes: ==

=== Notes: ===
D'après la section 2.15 [3], on a la correspondance suivante:
GRLIB IP Cores
Core Vendor
LEON3|0x01 (ie Gaisler Research [2] p49)
MCTRL|0x04 (ie European Space Agency [2]p49)
Ce qui nous permettra d'identifier le contrôleur mémoire

Voici quelques suggestions que l'on peut faire concernant le sniffeur de paquets:

Pour cela on utilise très largement le document [2] (GRLIB IP Library User’s Manual)

Lors d'une simulation du code VHDL, il est possible d'afficher le contenu du BAR (bank address registers).

Pour ce qui de la gestion de la prochaine tache à exécuter il y a possibilité de faire en sorte que notre composant:
-changer la priorité du master sur le bus AMBA
-empêcher l'accès en dur en modifiant le comportement du contrôleur de bus (1).

(1): Ceci ne fonctionnera que si les taches sont sur des partitions différentes et sur des processeurs indépendants.

Afin de réaliser le composant, il est envisageable de l'intégrer directement au sein du contrôleur de mémoire.

Celui devra donc récupérer le contenu des caches des processeurs afin de déterminé quel programme et en exécution.

=== Bibliographie: ===

[1] lien site gaisler
gaisler.com/index.php

[2] lien vers GRLIB IP Library User’s Manual
http://www.gaisler.com/products/grlib/grlib.pdf

[3] lien vers LEON3 GR-XC3S-1500 Template Design
http://www.gaisler.com/products/grlib/grip.pdf

P37 Creation d'un composant d'audit des accès cache mémoire sur un microprocesseur LEON3 simulé en FPGA

2015-02-16T08:24:30Z

Jvaessen : /* Semaine 20: */

= Rapport de Présoutenance =

http://projets-imasc.plil.net/mediawiki/images/0/05/Rapport_VAESSEN_presoutenance.pdf

= Presentation du projet =

Ce projet s'inscrit dans l'amélioration d'une solution d'IP pour un SoftCore implanté dans un FPGA.

== Cahier des charges ==

Il faudra créer un composant VHDL capable de:

1.
sniffer les paquets à destination de la SDRAM/RAM (via le memory controler)

2.
Vérifier le contenu du paquet savoir, le type d'accès (lecture/écriture) de la mémoire

3.
compter le nombre d'accès mémoire en écriture

4.
Différencier les zones mémoires qui sont accéder afin de déterminer l'application/taches qui est à l'origine.

Il faudra aussi, faire cohabiter deux (ou plus) SoftCore Leon3 communicants sur le même bus AMBA.

== Planning: ==

=== Semaine 1: ===
Décourverte de l'équipe et discussion concernant le projet

=== Semaine 2: ===
Mise en place des outils (cygwin64 avec "développement") et discussion concernant les possibilités offertes concernant le bus AMBA

=== Semaine 3: ===
Après plusieurs essais d'utilisation des paquets tcl/tk fournis avec cygwin, nous nous sommes aperçus que l'environnement cygwin ne semble pas utilisable pour le projet.
C'est pour cela que nous passons à une autre solution ie Msys cependant nous sommes en train de faire en sorte d'avoir la bonne version des outils TCL/TK.

=== Semaine 4: ===
Mise en place d'un SoftCore Leon3 sur un FPGA, exploration des modifications à apporter afin d'implémenter deux softcores avec un cache L2C.

=== Semaine 5: ===

Mise en place de multiple SoftCore Leon3 sur un FPGA, exploration des modifications à apporter afin d'implémenter deux softcores avec un cache L2C.

=== Semaine 6: ===

Abandon du cache L2C (composant manquant).

Compilation d'un "hello world" avec les outils et paramètres adéquats pour une architecture multicoeur.

Épluchage des documentations afin d'établir les signaux pertinents pour réaliser des compteurs qui auront les caractéristiques suivantes:

-une paire de compteurs pour la lecture et l'écriture en mémoire

-3 paire de compteur (PROM, RAM et SDRAM).

=== Semaine 7: ===

Étude du composant contrôleur mémoire afin d'y implanter le composant. Cela nous permettra d'accéder facilement aux signaux pertinents pour le contrôle du composant. On fera en sorte d'avoir une sortie sur un GPIO.

=== Semaine 8: ===

Au lieu d'essayer de comprendre comment fonctionne de manière précise l'abritrage du bus amba et comment fontionne le processus de selection d'un composant en fonction de l'adresse sur le bus, je me suis concentré sur les signaux reliées directement au mémoire (ram, rom et sdram) physique afin d'écrire mon composant.

L'idée serait d'utiliser ces signaux et faire une sortie sur un GPIO pour connaitre son état en le visualisant sur un oscilloscope.

=== Semaine 9: ===

Discussion et abandon de l'idée de la semaine 8, car une nouvelle contrainte a été fixée:

-le résultat de chacun des compteurs devra pouvoir être accessible à des adresses mémoire sur le bus amba donc accessible par le processeur.

=== Semaine 10: ===

Mise au propre du cahier des charges, et étude de la norme AMBA.

Test grmon RCP au travers Eclipse, infructueux, car la carte n'est pas reconnue.

== Semaine 11: ==

Écriture d'une ébauche de composant et étude des possibilités en fonction des signaux disponible dans le contrôleur mémoire.

== Semaine 12: ==

Étude bibliographique (documents de Gaisler, norme AMBA).

== Semaine 13: ==

Rédaction du rapport et préparation à la présoutenance.

== Semaine 14: ==

Prise en main de ModelSim PE 10.4, pour simuler le SOC (des erreurs sont encore à régler).

== Semaine 15: ==

Début de l'écriture du composant:
- correction des incohérences du design (au niveau du déclenchement du composant)
- amélioration du design (réduction de largeur des bus)

== Semaine 16: ==

Écriture et test du composant.

== Semaine 17: ==

Écriture de la fonction de la reconnaissance d'écriture dans un composant surveillé.

Écriture de la fonction permettant la reprogrammation du composant en valeur maximale.

Documentation sur l'utilitaire Chipscope Pro et son utilisation avec la carte.

== Semaine 18: ==

Tentative d'utilisation de Chipscope Pro, des erreurs sont constatées (ce qui est d'ailleurs évoqué lors de la configuration dans Chipscope : "connection to PAD or IBUFG net can cause error in PAR") (Qui provoque des erreurs lors de l'implémentation du design).

On rajoute des bascules D afin d'éviter ces erreurs, cependant nous ne verrons que l'état des bus au moment des fronts montants ou descendants (ce que est logique, car l'on ne peut pas échantillonné avec durée inférieur à celle de l'horloge).

L'implémentation avec est impossible à cause d'un signal "non existent", alors que celui existe belle et bien, donc on peut confirmer le fonctionnement du composant grâce à la simulation.

Test des commandes utiles au travers de grmon pour la version non modifiée et modifié du leon3.

On a commencé la réflexion sur un cache l2c primitif, ce composant permettrais de fournir directement le résultat si celui-ci à déjà était réalisé auparavant (Analogie: une personne que pose deux fois de suite la même question dans un intervalle borné relativement court).

== Semaine 19: ==

Début du rapport final.

Raccourcissement du code du composant.

Écriture des signaux de sortie: hrdata, hresp et hready, des fonctions de multiplexage en sortie seront nécessaires.

Ceci reste à confirmer grâce à un test sur la carte et/ou une simulation.

Nous avons réussi à faire fonctionner la simulation sur Modelsim PE.

Nous avons fait en sorte que le composant soit visible et reconnu lors de la simulation*

*à confirmer sans les attributes keep

== Semaine 20: ==

à faire:

-confirmer la présence du composant avec son compteur dans ModelSim PE

-tester une lecture si possible dans ModelSim PE et/ou sur la carte directement, faire des corrections en cas de besoin.

Début de la présentation de PFE à faire.

== Annexes: ==

=== Notes: ===
D'après la section 2.15 [3], on a la correspondance suivante:
GRLIB IP Cores
Core Vendor
LEON3|0x01 (ie Gaisler Research [2] p49)
MCTRL|0x04 (ie European Space Agency [2]p49)
Ce qui nous permettra d'identifier le contrôleur mémoire

Voici quelques suggestions que l'on peut faire concernant le sniffeur de paquets:

Pour cela on utilise très largement le document [2] (GRLIB IP Library User’s Manual)

Lors d'une simulation du code VHDL, il est possible d'afficher le contenu du BAR (bank address registers).

Pour ce qui de la gestion de la prochaine tache à exécuter il y a possibilité de faire en sorte que notre composant:
-changer la priorité du master sur le bus AMBA
-empêcher l'accès en dur en modifiant le comportement du contrôleur de bus (1).

(1): Ceci ne fonctionnera que si les taches sont sur des partitions différentes et sur des processeurs indépendants.

Afin de réaliser le composant, il est envisageable de l'intégrer directement au sein du contrôleur de mémoire.

Celui devra donc récupérer le contenu des caches des processeurs afin de déterminé quel programme et en exécution.

=== Bibliographie: ===

[1] lien site gaisler
gaisler.com/index.php

[2] lien vers GRLIB IP Library User’s Manual
http://www.gaisler.com/products/grlib/grlib.pdf

[3] lien vers LEON3 GR-XC3S-1500 Template Design
http://www.gaisler.com/products/grlib/grip.pdf

P37 Creation d'un composant d'audit des accès cache mémoire sur un microprocesseur LEON3 simulé en FPGA

2015-02-16T08:14:49Z

Jvaessen : /* Semaine 18: */

= Rapport de Présoutenance =

http://projets-imasc.plil.net/mediawiki/images/0/05/Rapport_VAESSEN_presoutenance.pdf

= Presentation du projet =

Ce projet s'inscrit dans l'amélioration d'une solution d'IP pour un SoftCore implanté dans un FPGA.

== Cahier des charges ==

Il faudra créer un composant VHDL capable de:

1.
sniffer les paquets à destination de la SDRAM/RAM (via le memory controler)

2.
Vérifier le contenu du paquet savoir, le type d'accès (lecture/écriture) de la mémoire

3.
compter le nombre d'accès mémoire en écriture

4.
Différencier les zones mémoires qui sont accéder afin de déterminer l'application/taches qui est à l'origine.

Il faudra aussi, faire cohabiter deux (ou plus) SoftCore Leon3 communicants sur le même bus AMBA.

== Planning: ==

=== Semaine 1: ===
Décourverte de l'équipe et discussion concernant le projet

=== Semaine 2: ===
Mise en place des outils (cygwin64 avec "développement") et discussion concernant les possibilités offertes concernant le bus AMBA

=== Semaine 3: ===
Après plusieurs essais d'utilisation des paquets tcl/tk fournis avec cygwin, nous nous sommes aperçus que l'environnement cygwin ne semble pas utilisable pour le projet.
C'est pour cela que nous passons à une autre solution ie Msys cependant nous sommes en train de faire en sorte d'avoir la bonne version des outils TCL/TK.

=== Semaine 4: ===
Mise en place d'un SoftCore Leon3 sur un FPGA, exploration des modifications à apporter afin d'implémenter deux softcores avec un cache L2C.

=== Semaine 5: ===

Mise en place de multiple SoftCore Leon3 sur un FPGA, exploration des modifications à apporter afin d'implémenter deux softcores avec un cache L2C.

=== Semaine 6: ===

Abandon du cache L2C (composant manquant).

Compilation d'un "hello world" avec les outils et paramètres adéquats pour une architecture multicoeur.

Épluchage des documentations afin d'établir les signaux pertinents pour réaliser des compteurs qui auront les caractéristiques suivantes:

-une paire de compteurs pour la lecture et l'écriture en mémoire

-3 paire de compteur (PROM, RAM et SDRAM).

=== Semaine 7: ===

Étude du composant contrôleur mémoire afin d'y implanter le composant. Cela nous permettra d'accéder facilement aux signaux pertinents pour le contrôle du composant. On fera en sorte d'avoir une sortie sur un GPIO.

=== Semaine 8: ===

Au lieu d'essayer de comprendre comment fonctionne de manière précise l'abritrage du bus amba et comment fontionne le processus de selection d'un composant en fonction de l'adresse sur le bus, je me suis concentré sur les signaux reliées directement au mémoire (ram, rom et sdram) physique afin d'écrire mon composant.

L'idée serait d'utiliser ces signaux et faire une sortie sur un GPIO pour connaitre son état en le visualisant sur un oscilloscope.

=== Semaine 9: ===

Discussion et abandon de l'idée de la semaine 8, car une nouvelle contrainte a été fixée:

-le résultat de chacun des compteurs devra pouvoir être accessible à des adresses mémoire sur le bus amba donc accessible par le processeur.

=== Semaine 10: ===

Mise au propre du cahier des charges, et étude de la norme AMBA.

Test grmon RCP au travers Eclipse, infructueux, car la carte n'est pas reconnue.

== Semaine 11: ==

Écriture d'une ébauche de composant et étude des possibilités en fonction des signaux disponible dans le contrôleur mémoire.

== Semaine 12: ==

Étude bibliographique (documents de Gaisler, norme AMBA).

== Semaine 13: ==

Rédaction du rapport et préparation à la présoutenance.

== Semaine 14: ==

Prise en main de ModelSim PE 10.4, pour simuler le SOC (des erreurs sont encore à régler).

== Semaine 15: ==

Début de l'écriture du composant:
- correction des incohérences du design (au niveau du déclenchement du composant)
- amélioration du design (réduction de largeur des bus)

== Semaine 16: ==

Écriture et test du composant.

== Semaine 17: ==

Écriture de la fonction de la reconnaissance d'écriture dans un composant surveillé.

Écriture de la fonction permettant la reprogrammation du composant en valeur maximale.

Documentation sur l'utilitaire Chipscope Pro et son utilisation avec la carte.

== Semaine 18: ==

Tentative d'utilisation de Chipscope Pro, des erreurs sont constatées (ce qui est d'ailleurs évoqué lors de la configuration dans Chipscope : "connection to PAD or IBUFG net can cause error in PAR") (Qui provoque des erreurs lors de l'implémentation du design).

On rajoute des bascules D afin d'éviter ces erreurs, cependant nous ne verrons que l'état des bus au moment des fronts montants ou descendants (ce que est logique, car l'on ne peut pas échantillonné avec durée inférieur à celle de l'horloge).

L'implémentation avec est impossible à cause d'un signal "non existent", alors que celui existe belle et bien, donc on peut confirmer le fonctionnement du composant grâce à la simulation.

Test des commandes utiles au travers de grmon pour la version non modifiée et modifié du leon3.

On a commencé la réflexion sur un cache l2c primitif, ce composant permettrais de fournir directement le résultat si celui-ci à déjà était réalisé auparavant (Analogie: une personne que pose deux fois de suite la même question dans un intervalle borné relativement court).

== Semaine 19: ==

-en cours- Début du rapport final.

-en cours- Raccourcissement du code.

-en cours- Écriture des signaux de sortie: hrdata, hresp et hready, des fonctions de multiplexage en sortie seront nécessaires.

abandonné:
-améliorer le modèle de simulation grâce à la simulation ModelSim PE

== Annexes: ==

=== Notes: ===
D'après la section 2.15 [3], on a la correspondance suivante:
GRLIB IP Cores
Core Vendor
LEON3|0x01 (ie Gaisler Research [2] p49)
MCTRL|0x04 (ie European Space Agency [2]p49)
Ce qui nous permettra d'identifier le contrôleur mémoire

Voici quelques suggestions que l'on peut faire concernant le sniffeur de paquets:

Pour cela on utilise très largement le document [2] (GRLIB IP Library User’s Manual)

Lors d'une simulation du code VHDL, il est possible d'afficher le contenu du BAR (bank address registers).

Pour ce qui de la gestion de la prochaine tache à exécuter il y a possibilité de faire en sorte que notre composant:
-changer la priorité du master sur le bus AMBA
-empêcher l'accès en dur en modifiant le comportement du contrôleur de bus (1).

(1): Ceci ne fonctionnera que si les taches sont sur des partitions différentes et sur des processeurs indépendants.

Afin de réaliser le composant, il est envisageable de l'intégrer directement au sein du contrôleur de mémoire.

Celui devra donc récupérer le contenu des caches des processeurs afin de déterminé quel programme et en exécution.

=== Bibliographie: ===

[1] lien site gaisler
gaisler.com/index.php

[2] lien vers GRLIB IP Library User’s Manual
http://www.gaisler.com/products/grlib/grlib.pdf

[3] lien vers LEON3 GR-XC3S-1500 Template Design
http://www.gaisler.com/products/grlib/grip.pdf

P37 Creation d'un composant d'audit des accès cache mémoire sur un microprocesseur LEON3 simulé en FPGA

2015-02-06T14:07:13Z

Jvaessen : /* Semaine 18: */

= Rapport de Présoutenance =

http://projets-imasc.plil.net/mediawiki/images/0/05/Rapport_VAESSEN_presoutenance.pdf

= Presentation du projet =

Ce projet s'inscrit dans l'amélioration d'une solution d'IP pour un SoftCore implanté dans un FPGA.

== Cahier des charges ==

Il faudra créer un composant VHDL capable de:

1.
sniffer les paquets à destination de la SDRAM/RAM (via le memory controler)

2.
Vérifier le contenu du paquet savoir, le type d'accès (lecture/écriture) de la mémoire

3.
compter le nombre d'accès mémoire en écriture

4.
Différencier les zones mémoires qui sont accéder afin de déterminer l'application/taches qui est à l'origine.

Il faudra aussi, faire cohabiter deux (ou plus) SoftCore Leon3 communicants sur le même bus AMBA.

== Planning: ==

=== Semaine 1: ===
Décourverte de l'équipe et discussion concernant le projet

=== Semaine 2: ===
Mise en place des outils (cygwin64 avec "développement") et discussion concernant les possibilités offertes concernant le bus AMBA

=== Semaine 3: ===
Après plusieurs essais d'utilisation des paquets tcl/tk fournis avec cygwin, nous nous sommes aperçus que l'environnement cygwin ne semble pas utilisable pour le projet.
C'est pour cela que nous passons à une autre solution ie Msys cependant nous sommes en train de faire en sorte d'avoir la bonne version des outils TCL/TK.

=== Semaine 4: ===
Mise en place d'un SoftCore Leon3 sur un FPGA, exploration des modifications à apporter afin d'implémenter deux softcores avec un cache L2C.

=== Semaine 5: ===

Mise en place de multiple SoftCore Leon3 sur un FPGA, exploration des modifications à apporter afin d'implémenter deux softcores avec un cache L2C.

=== Semaine 6: ===

Abandon du cache L2C (composant manquant).

Compilation d'un "hello world" avec les outils et paramètres adéquats pour une architecture multicoeur.

Épluchage des documentations afin d'établir les signaux pertinents pour réaliser des compteurs qui auront les caractéristiques suivantes:

-une paire de compteurs pour la lecture et l'écriture en mémoire

-3 paire de compteur (PROM, RAM et SDRAM).

=== Semaine 7: ===

Étude du composant contrôleur mémoire afin d'y implanter le composant. Cela nous permettra d'accéder facilement aux signaux pertinents pour le contrôle du composant. On fera en sorte d'avoir une sortie sur un GPIO.

=== Semaine 8: ===

Au lieu d'essayer de comprendre comment fonctionne de manière précise l'abritrage du bus amba et comment fontionne le processus de selection d'un composant en fonction de l'adresse sur le bus, je me suis concentré sur les signaux reliées directement au mémoire (ram, rom et sdram) physique afin d'écrire mon composant.

L'idée serait d'utiliser ces signaux et faire une sortie sur un GPIO pour connaitre son état en le visualisant sur un oscilloscope.

=== Semaine 9: ===

Discussion et abandon de l'idée de la semaine 8, car une nouvelle contrainte a été fixée:

-le résultat de chacun des compteurs devra pouvoir être accessible à des adresses mémoire sur le bus amba donc accessible par le processeur.

=== Semaine 10: ===

Mise au propre du cahier des charges, et étude de la norme AMBA.

Test grmon RCP au travers Eclipse, infructueux, car la carte n'est pas reconnue.

== Semaine 11: ==

Écriture d'une ébauche de composant et étude des possibilités en fonction des signaux disponible dans le contrôleur mémoire.

== Semaine 12: ==

Étude bibliographique (documents de Gaisler, norme AMBA).

== Semaine 13: ==

Rédaction du rapport et préparation à la présoutenance.

== Semaine 14: ==

Prise en main de ModelSim PE 10.4, pour simuler le SOC (des erreurs sont encore à régler).

== Semaine 15: ==

Début de l'écriture du composant:
- correction des incohérences du design (au niveau du déclenchement du composant)
- amélioration du design (réduction de largeur des bus)

== Semaine 16: ==

Écriture et test du composant.

== Semaine 17: ==

Écriture de la fonction de la reconnaissance d'écriture dans un composant surveillé.

Écriture de la fonction permettant la reprogrammation du composant en valeur maximale.

Documentation sur l'utilitaire Chipscope Pro et son utilisation avec la carte.

== Semaine 18: ==

Tentative d'utilisation de Chipscope Pro, des erreurs sont constatées (ce qui est d'ailleurs évoqué lors de la configuration dans Chipscope : "connection to PAD or IBUFG net can cause error in PAR") (Qui provoque des erreurs lors de l'implémentation du design).

On rajoutera des bascules D afin d'éviter ces erreurs, cependant nous ne verrons que l'état des bus au moment des fronts montants ou descendants (ce que est logique, car l'on ne peut pas échantillonné avec durée inférieur à celle de l'horloge).

Test des commandes utiles au travers de grmon pour la version non modifiée et modifié du leon3.

On a commencé la réflexion sur un cache l2c primitif, ce composant permettrais de fournir directement le résultat si celui-ci à déjà était réalisé auparavant (Analogie: une personne que pose deux fois de suite la même question dans un intervalle borné relativement court).

== Semaine 19: ==

-en cours- Début du rapport final.

-en cours- Raccourcissement du code.

-en cours- Écriture des signaux de sortie: hrdata, hresp et hready, des fonctions de multiplexage en sortie seront nécessaires.

abandonné:
-améliorer le modèle de simulation grâce à la simulation ModelSim PE

== Annexes: ==

=== Notes: ===
D'après la section 2.15 [3], on a la correspondance suivante:
GRLIB IP Cores
Core Vendor
LEON3|0x01 (ie Gaisler Research [2] p49)
MCTRL|0x04 (ie European Space Agency [2]p49)
Ce qui nous permettra d'identifier le contrôleur mémoire

Voici quelques suggestions que l'on peut faire concernant le sniffeur de paquets:

Pour cela on utilise très largement le document [2] (GRLIB IP Library User’s Manual)

Lors d'une simulation du code VHDL, il est possible d'afficher le contenu du BAR (bank address registers).

Pour ce qui de la gestion de la prochaine tache à exécuter il y a possibilité de faire en sorte que notre composant:
-changer la priorité du master sur le bus AMBA
-empêcher l'accès en dur en modifiant le comportement du contrôleur de bus (1).

(1): Ceci ne fonctionnera que si les taches sont sur des partitions différentes et sur des processeurs indépendants.

Afin de réaliser le composant, il est envisageable de l'intégrer directement au sein du contrôleur de mémoire.

Celui devra donc récupérer le contenu des caches des processeurs afin de déterminé quel programme et en exécution.

=== Bibliographie: ===

[1] lien site gaisler
gaisler.com/index.php

[2] lien vers GRLIB IP Library User’s Manual
http://www.gaisler.com/products/grlib/grlib.pdf

[3] lien vers LEON3 GR-XC3S-1500 Template Design
http://www.gaisler.com/products/grlib/grip.pdf

P37 Creation d'un composant d'audit des accès cache mémoire sur un microprocesseur LEON3 simulé en FPGA

2015-01-30T17:14:01Z

Jvaessen : /* Semaine 17: */

= Rapport de Présoutenance =

http://projets-imasc.plil.net/mediawiki/images/0/05/Rapport_VAESSEN_presoutenance.pdf

= Presentation du projet =

Ce projet s'inscrit dans l'amélioration d'une solution d'IP pour un SoftCore implanté dans un FPGA.

== Cahier des charges ==

Il faudra créer un composant VHDL capable de:

1.
sniffer les paquets à destination de la SDRAM/RAM (via le memory controler)

2.
Vérifier le contenu du paquet savoir, le type d'accès (lecture/écriture) de la mémoire

3.
compter le nombre d'accès mémoire en écriture

4.
Différencier les zones mémoires qui sont accéder afin de déterminer l'application/taches qui est à l'origine.

Il faudra aussi, faire cohabiter deux (ou plus) SoftCore Leon3 communicants sur le même bus AMBA.

== Planning: ==

=== Semaine 1: ===
Décourverte de l'équipe et discussion concernant le projet

=== Semaine 2: ===
Mise en place des outils (cygwin64 avec "développement") et discussion concernant les possibilités offertes concernant le bus AMBA

=== Semaine 3: ===
Après plusieurs essais d'utilisation des paquets tcl/tk fournis avec cygwin, nous nous sommes aperçus que l'environnement cygwin ne semble pas utilisable pour le projet.
C'est pour cela que nous passons à une autre solution ie Msys cependant nous sommes en train de faire en sorte d'avoir la bonne version des outils TCL/TK.

=== Semaine 4: ===
Mise en place d'un SoftCore Leon3 sur un FPGA, exploration des modifications à apporter afin d'implémenter deux softcores avec un cache L2C.

=== Semaine 5: ===

Mise en place de multiple SoftCore Leon3 sur un FPGA, exploration des modifications à apporter afin d'implémenter deux softcores avec un cache L2C.

=== Semaine 6: ===

Abandon du cache L2C (composant manquant).

Compilation d'un "hello world" avec les outils et paramètres adéquats pour une architecture multicoeur.

Épluchage des documentations afin d'établir les signaux pertinents pour réaliser des compteurs qui auront les caractéristiques suivantes:

-une paire de compteurs pour la lecture et l'écriture en mémoire

-3 paire de compteur (PROM, RAM et SDRAM).

=== Semaine 7: ===

Étude du composant contrôleur mémoire afin d'y implanter le composant. Cela nous permettra d'accéder facilement aux signaux pertinents pour le contrôle du composant. On fera en sorte d'avoir une sortie sur un GPIO.

=== Semaine 8: ===

Au lieu d'essayer de comprendre comment fonctionne de manière précise l'abritrage du bus amba et comment fontionne le processus de selection d'un composant en fonction de l'adresse sur le bus, je me suis concentré sur les signaux reliées directement au mémoire (ram, rom et sdram) physique afin d'écrire mon composant.

L'idée serait d'utiliser ces signaux et faire une sortie sur un GPIO pour connaitre son état en le visualisant sur un oscilloscope.

=== Semaine 9: ===

Discussion et abandon de l'idée de la semaine 8, car une nouvelle contrainte a été fixée:

-le résultat de chacun des compteurs devra pouvoir être accessible à des adresses mémoire sur le bus amba donc accessible par le processeur.

=== Semaine 10: ===

Mise au propre du cahier des charges, et étude de la norme AMBA.

Test grmon RCP au travers Eclipse, infructueux, car la carte n'est pas reconnue.

== Semaine 11: ==

Écriture d'une ébauche de composant et étude des possibilités en fonction des signaux disponible dans le contrôleur mémoire.

== Semaine 12: ==

Étude bibliographique (documents de Gaisler, norme AMBA).

== Semaine 13: ==

Rédaction du rapport et préparation à la présoutenance.

== Semaine 14: ==

Prise en main de ModelSim PE 10.4, pour simuler le SOC (des erreurs sont encore à régler).

== Semaine 15: ==

Début de l'écriture du composant:
- correction des incohérences du design (au niveau du déclenchement du composant)
- amélioration du design (réduction de largeur des bus)

== Semaine 16: ==

Écriture et test du composant.

== Semaine 17: ==

Écriture de la fonction de la reconnaissance d'écriture dans un composant surveillé.

Écriture de la fonction permettant la reprogrammation du composant en valeur maximale.

Documentation sur l'utilitaire Chipscope Pro et son utilisation avec la carte.

-en cours- Écriture des signaux de sortie: hrdata, hresp et hready, des fonctions de multiplexage en sortie seront nécessaires.

TODO:
-améliorer le modèle de simulation grâce à la simulation ModelSim PE

== Annexes: ==

=== Notes: ===
D'après la section 2.15 [3], on a la correspondance suivante:
GRLIB IP Cores
Core Vendor
LEON3|0x01 (ie Gaisler Research [2] p49)
MCTRL|0x04 (ie European Space Agency [2]p49)
Ce qui nous permettra d'identifier le contrôleur mémoire

Voici quelques suggestions que l'on peut faire concernant le sniffeur de paquets:

Pour cela on utilise très largement le document [2] (GRLIB IP Library User’s Manual)

Lors d'une simulation du code VHDL, il est possible d'afficher le contenu du BAR (bank address registers).

Pour ce qui de la gestion de la prochaine tache à exécuter il y a possibilité de faire en sorte que notre composant:
-changer la priorité du master sur le bus AMBA
-empêcher l'accès en dur en modifiant le comportement du contrôleur de bus (1).

(1): Ceci ne fonctionnera que si les taches sont sur des partitions différentes et sur des processeurs indépendants.

Afin de réaliser le composant, il est envisageable de l'intégrer directement au sein du contrôleur de mémoire.

Celui devra donc récupérer le contenu des caches des processeurs afin de déterminé quel programme et en exécution.

=== Bibliographie: ===

[1] lien site gaisler
gaisler.com/index.php

[2] lien vers GRLIB IP Library User’s Manual
http://www.gaisler.com/products/grlib/grlib.pdf

[3] lien vers LEON3 GR-XC3S-1500 Template Design
http://www.gaisler.com/products/grlib/grip.pdf

P37 Creation d'un composant d'audit des accès cache mémoire sur un microprocesseur LEON3 simulé en FPGA

2015-01-25T10:21:24Z

Jvaessen : /* Semaine 12: */

P37 Creation d'un composant d'audit des accès cache mémoire sur un microprocesseur LEON3 simulé en FPGA

2015-01-25T10:21:05Z

Jvaessen : /* Semaine 10: */

Fichier:Rapport VAESSEN presoutenance.pdf

2014-12-17T21:25:17Z

Jvaessen : a téléversé une nouvelle version de « Fichier:Rapport VAESSEN presoutenance.pdf » : Révision numéro 2 du rapport de présoutenance VAESSEN IMA5 2014-2015

Rapport Présoutenance PFE VAESSEN IMA5 SC 2014-2015

Projets IMA5 2014/2015

2014-12-17T05:36:55Z

Jvaessen : /* Répartition des binômes */

P37 Creation d'un composant d'audit des accès cache mémoire sur un microprocesseur LEON3 simulé en FPGA

2014-12-17T05:31:06Z

Jvaessen : /* Presentation du projet */

Fichier:Rapport VAESSEN presoutenance.pdf

2014-12-17T05:29:33Z

Jvaessen : Rapport Présoutenance PFE VAESSEN IMA5 SC 2014-2015

Rapport Présoutenance PFE VAESSEN IMA5 SC 2014-2015

P37 Creation d'un composant d'audit des accès cache mémoire sur un microprocesseur LEON3 simulé en FPGA

2014-12-06T07:45:19Z

Jvaessen : Ajout du travail effectué les trois dernières semaines

= Presentation du projet =

Ce projet s'inscrit dans l'amélioration d'une solution d'IP pour un SoftCore implanté dans un FPGA.

== Cahier des charges ==

Il faudra créer un composant VHDL capable de:

1.
sniffer les paquets à destination de la SDRAM/RAM (via le memory controler)

2.
Vérifier le contenu du paquet savoir, le type d'accès (lecture/écriture) de la mémoire

3.
compter le nombre d'accès mémoire en écriture

4.
Différencier les zones mémoires qui sont accéder afin de déterminer l'application/taches qui est à l'origine.

Il faudra aussi, faire cohabiter deux (ou plus) SoftCore Leon3 communicants sur le même bus AMBA.

== Planning: ==

=== Semaine 1: ===
Décourverte de l'équipe et discussion concernant le projet

=== Semaine 2: ===
Mise en place des outils (cygwin64 avec "développement") et discussion concernant les possibilités offertes concernant le bus AMBA

=== Semaine 3: ===
Après plusieurs essais d'utilisation des paquets tcl/tk fournis avec cygwin, nous nous sommes aperçus que l'environnement cygwin ne semble pas utilisable pour le projet.
C'est pour cela que nous passons à une autre solution ie Msys cependant nous sommes en train de faire en sorte d'avoir la bonne version des outils TCL/TK.

=== Semaine 4: ===
Mise en place d'un SoftCore Leon3 sur un FPGA, exploration des modifications à apporter afin d'implémenter deux softcores avec un cache L2C.

=== Semaine 5: ===

Mise en place de multiple SoftCore Leon3 sur un FPGA, exploration des modifications à apporter afin d'implémenter deux softcores avec un cache L2C.

=== Semaine 6: ===

Abandon du cache L2C (composant manquant).

Compilation d'un "hello world" avec les outils et paramètres adéquats pour une architecture multicoeur.

Épluchage des documentations afin d'établir les signaux pertinents pour réaliser des compteurs qui auront les caractéristiques suivantes:

-une paire de compteurs pour la lecture et l'écriture en mémoire

-3 paire de compteur (PROM, RAM et SDRAM).

=== Semaine 7: ===

Étude du composant contrôleur mémoire afin d'y implanter le composant. Cela nous permettra d'accéder facilement aux signaux pertinents pour le contrôle du composant. On fera en sorte d'avoir une sortie sur un GPIO.

=== Semaine 8: ===

Au lieu d'essayer de comprendre comment fonctionne de manière précise l'abritrage du bus amba et comment fontionne le processus de selection d'un composant en fonction de l'adresse sur le bus, je me suis concentré sur les signaux reliées directement au mémoire (ram, rom et sdram) physique afin d'écrire mon composant.

L'idée serait d'utiliser ces signaux et faire une sortie sur un GPIO pour connaitre son état en le visualisant sur un oscilloscope.

=== Semaine 9: ===

Discussion et abandon de l'idée de la semaine 8, car une nouvelle contrainte a été fixée:

-le résultat de chacun des compteurs devra pouvoir être accessible à des adresses mémoire sur le bus amba donc accessible par le processeur.

=== Semaine 10: ===

(En cours: Mise au propre du cahier des charges)

== Annexes: ==

=== Notes: ===
D'après la section 2.15 [3], on a la correspondance suivante:
GRLIB IP Cores
Core Vendor
LEON3|0x01 (ie Gaisler Research [2] p49)
MCTRL|0x04 (ie European Space Agency [2]p49)
Ce qui nous permettra d'identifier le contrôleur mémoire

Voici quelques suggestions que l'on peut faire concernant le sniffeur de paquets:

Pour cela on utilise très largement le document [2] (GRLIB IP Library User’s Manual)

Lors d'une simulation du code VHDL, il est possible d'afficher le contenu du BAR (bank address registers).

Pour ce qui de la gestion de la prochaine tache à exécuter il y a possibilité de faire en sorte que notre composant:
-changer la priorité du master sur le bus AMBA
-empêcher l'accès en dur en modifiant le comportement du contrôleur de bus (1).

(1): Ceci ne fonctionnera que si les taches sont sur des partitions différentes et sur des processeurs indépendants.

Afin de réaliser le composant, il est envisageable de l'intégrer directement au sein du contrôleur de mémoire.

Celui devra donc récupérer le contenu des caches des processeurs afin de déterminé quel programme et en exécution.

=== Bibliographie: ===

[1] lien site gaisler
gaisler.com/index.php

[2] lien vers GRLIB IP Library User’s Manual
http://www.gaisler.com/products/grlib/grlib.pdf

[3] lien vers LEON3 GR-XC3S-1500 Template Design
http://www.gaisler.com/products/grlib/grip.pdf

P37 Creation d'un composant d'audit des accès cache mémoire sur un microprocesseur LEON3 simulé en FPGA

2014-11-16T17:07:29Z

Jvaessen : /* Semaine 6: */

= Presentation du projet =

Ce projet s'inscrit dans l'amélioration d'une solution d'IP pour un SoftCore implanté dans un FPGA.

== Cahier des charges ==

Il faudra créer un composant VHDL capable de:

1.
sniffer les paquets à destination de la SDRAM/RAM (via le memory controler)

2.
Vérifier le contenu du paquet savoir, le type d'accès (lecture/écriture) de la mémoire

3.
compter le nombre d'accès mémoire en écriture

4.
Différencier les zones mémoires qui sont accéder afin de déterminer l'application/taches qui est à l'origine.

Il faudra aussi, faire cohabiter deux (ou plus) SoftCore Leon3 communicants sur le même bus AMBA.

== Planning: ==

=== Semaine 1: ===
Décourverte de l'équipe et discussion concernant le projet

=== Semaine 2: ===
Mise en place des outils (cygwin64 avec "développement") et discussion concernant les possibilités offertes concernant le bus AMBA

=== Semaine 3: ===
Après plusieurs essais d'utilisation des paquets tcl/tk fournis avec cygwin, nous nous sommes aperçus que l'environnement cygwin ne semble pas utilisable pour le projet.
C'est pour cela que nous passons à une autre solution ie Msys cependant nous sommes en train de faire en sorte d'avoir la bonne version des outils TCL/TK.

=== Semaine 4: ===
Mise en place d'un SoftCore Leon3 sur un FPGA, exploration des modifications à apporter afin d'implémenter deux softcores avec un cache L2C.

=== Semaine 5: ===

Mise en place de multiple SoftCore Leon3 sur un FPGA, exploration des modifications à apporter afin d'implémenter deux softcores avec un cache L2C.

=== Semaine 6: ===

Abandon du cache L2C (composant manquant).

Compilation d'un "hello world" avec les outils et paramètres adéquats pour une architecture multicoeur.

Épluchage des documentations afin d'établir les signaux pertinents pour réaliser des compteurs qui auront les caractéristiques suivantes:

-une paire de compteurs pour la lecture et l'écriture en mémoire

-3 paire de compteur (PROM, RAM et SDRAM).

=== Semaine 7: ===

Étude du composant contrôleur mémoire afin d'y implanter le composant. Cela nous permettra d'accéder facilement aux signaux pertinents pour le contrôle du composant. On fera en sorte d'avoir une sortie sur un GPIO.

== Annexes: ==

=== Notes: ===
D'après la section 2.15 [3], on a la correspondance suivante:
GRLIB IP Cores
Core Vendor
LEON3|0x01 (ie Gaisler Research [2] p49)
MCTRL|0x04 (ie European Space Agency [2]p49)
Ce qui nous permettra d'identifier le contrôleur mémoire

Voici quelques suggestions que l'on peut faire concernant le sniffeur de paquets:

Pour cela on utilise très largement le document [2] (GRLIB IP Library User’s Manual)

Lors d'une simulation du code VHDL, il est possible d'afficher le contenu du BAR (bank address registers).

Pour ce qui de la gestion de la prochaine tache à exécuter il y a possibilité de faire en sorte que notre composant:
-changer la priorité du master sur le bus AMBA
-empêcher l'accès en dur en modifiant le comportement du contrôleur de bus (1).

(1): Ceci ne fonctionnera que si les taches sont sur des partitions différentes et sur des processeurs indépendants.

Afin de réaliser le composant, il est envisageable de l'intégrer directement au sein du contrôleur de mémoire.

Celui devra donc récupérer le contenu des caches des processeurs afin de déterminé quel programme et en exécution.

=== Bibliographie: ===

[1] lien site gaisler
gaisler.com/index.php

[2] lien vers GRLIB IP Library User’s Manual
http://www.gaisler.com/products/grlib/grlib.pdf

[3] lien vers LEON3 GR-XC3S-1500 Template Design
http://www.gaisler.com/products/grlib/grip.pdf

P37 Creation d'un composant d'audit des accès cache mémoire sur un microprocesseur LEON3 simulé en FPGA

2014-11-16T17:07:15Z

Jvaessen : /* Semaine 6: */

= Presentation du projet =

Ce projet s'inscrit dans l'amélioration d'une solution d'IP pour un SoftCore implanté dans un FPGA.

== Cahier des charges ==

Il faudra créer un composant VHDL capable de:

1.
sniffer les paquets à destination de la SDRAM/RAM (via le memory controler)

2.
Vérifier le contenu du paquet savoir, le type d'accès (lecture/écriture) de la mémoire

3.
compter le nombre d'accès mémoire en écriture

4.
Différencier les zones mémoires qui sont accéder afin de déterminer l'application/taches qui est à l'origine.

Il faudra aussi, faire cohabiter deux (ou plus) SoftCore Leon3 communicants sur le même bus AMBA.

== Planning: ==

=== Semaine 1: ===
Décourverte de l'équipe et discussion concernant le projet

=== Semaine 2: ===
Mise en place des outils (cygwin64 avec "développement") et discussion concernant les possibilités offertes concernant le bus AMBA

=== Semaine 3: ===
Après plusieurs essais d'utilisation des paquets tcl/tk fournis avec cygwin, nous nous sommes aperçus que l'environnement cygwin ne semble pas utilisable pour le projet.
C'est pour cela que nous passons à une autre solution ie Msys cependant nous sommes en train de faire en sorte d'avoir la bonne version des outils TCL/TK.

=== Semaine 4: ===
Mise en place d'un SoftCore Leon3 sur un FPGA, exploration des modifications à apporter afin d'implémenter deux softcores avec un cache L2C.

=== Semaine 5: ===

Mise en place de multiple SoftCore Leon3 sur un FPGA, exploration des modifications à apporter afin d'implémenter deux softcores avec un cache L2C.

=== Semaine 6: ===

Abandon du cache L2C (composant manquant).

Compilation d'un "hello world" avec les outils et paramètres adéquats pour une architecture multicoeur.

Épluchage des documentations afin d'établir les signaux pertinents pour réaliser des compteurs qui auront les caractéristiques suivantes:

-une paire de compteurs pour la lecture et l'écriture en mémoire

-3 paire de compteur (PROM, RAM et SDRAM).

=== Semaine 7: ===

Étude du composant contrôleur mémoire afin d'y implanter le composant. Cela nous permettra d'accéder facilement aux signaux pertinents pour le contrôle du composant. On fera en sorte d'avoir une sortie sur un GPIO.

== Annexes: ==

=== Notes: ===
D'après la section 2.15 [3], on a la correspondance suivante:
GRLIB IP Cores
Core Vendor
LEON3|0x01 (ie Gaisler Research [2] p49)
MCTRL|0x04 (ie European Space Agency [2]p49)
Ce qui nous permettra d'identifier le contrôleur mémoire

Voici quelques suggestions que l'on peut faire concernant le sniffeur de paquets:

Pour cela on utilise très largement le document [2] (GRLIB IP Library User’s Manual)

Lors d'une simulation du code VHDL, il est possible d'afficher le contenu du BAR (bank address registers).

Pour ce qui de la gestion de la prochaine tache à exécuter il y a possibilité de faire en sorte que notre composant:
-changer la priorité du master sur le bus AMBA
-empêcher l'accès en dur en modifiant le comportement du contrôleur de bus (1).

(1): Ceci ne fonctionnera que si les taches sont sur des partitions différentes et sur des processeurs indépendants.

Afin de réaliser le composant, il est envisageable de l'intégrer directement au sein du contrôleur de mémoire.

Celui devra donc récupérer le contenu des caches des processeurs afin de déterminé quel programme et en exécution.

=== Bibliographie: ===

[1] lien site gaisler
gaisler.com/index.php

[2] lien vers GRLIB IP Library User’s Manual
http://www.gaisler.com/products/grlib/grlib.pdf

[3] lien vers LEON3 GR-XC3S-1500 Template Design
http://www.gaisler.com/products/grlib/grip.pdf

P37 Creation d'un composant d'audit des accès cache mémoire sur un microprocesseur LEON3 simulé en FPGA

2014-11-09T21:28:12Z

Jvaessen : /* Semaine 5: */

= Presentation du projet =

Ce projet s'inscrit dans l'amélioration d'une solution d'IP pour un SoftCore implanté dans un FPGA.

== Cahier des charges ==

Il faudra créer un composant VHDL capable de:

1.
sniffer les paquets à destination de la SDRAM/RAM (via le memory controler)

2.
Vérifier le contenu du paquet savoir, le type d'accès (lecture/écriture) de la mémoire

3.
compter le nombre d'accès mémoire en écriture

4.
Différencier les zones mémoires qui sont accéder afin de déterminer l'application/taches qui est à l'origine.

Il faudra aussi, faire cohabiter deux (ou plus) SoftCore Leon3 communicants sur le même bus AMBA.

== Planning: ==

=== Semaine 1: ===
Décourverte de l'équipe et discussion concernant le projet

=== Semaine 2: ===
Mise en place des outils (cygwin64 avec "développement") et discussion concernant les possibilités offertes concernant le bus AMBA

=== Semaine 3: ===
Après plusieurs essais d'utilisation des paquets tcl/tk fournis avec cygwin, nous nous sommes aperçus que l'environnement cygwin ne semble pas utilisable pour le projet.
C'est pour cela que nous passons à une autre solution ie Msys cependant nous sommes en train de faire en sorte d'avoir la bonne version des outils TCL/TK.

=== Semaine 4: ===
Mise en place d'un SoftCore Leon3 sur un FPGA, exploration des modifications à apporter afin d'implémenter deux softcores avec un cache L2C.

=== Semaine 5: ===

Mise en place de multiple SoftCore Leon3 sur un FPGA, exploration des modifications à apporter afin d'implémenter deux softcores avec un cache L2C.

=== Semaine 6: ===

Abandon du cache L2C (composant manquant).

Compilation d'un "hello world" avec les outils et paramètres adéquats pour une architecture multicoeur.

Épluchage des documentations afin d'établir les signaux pertinents pour réaliser des compteurs qui auront les caractéristiques suivantes:

-une paire de compteurs pour la lecture et l'écriture en mémoire

-3 paire de compteur (PROM, RAM et SDRAM).

== Annexes: ==

=== Notes: ===
D'après la section 2.15 [3], on a la correspondance suivante:
GRLIB IP Cores
Core Vendor
LEON3|0x01 (ie Gaisler Research [2] p49)
MCTRL|0x04 (ie European Space Agency [2]p49)
Ce qui nous permettra d'identifier le contrôleur mémoire

Voici quelques suggestions que l'on peut faire concernant le sniffeur de paquets:

Pour cela on utilise très largement le document [2] (GRLIB IP Library User’s Manual)

Lors d'une simulation du code VHDL, il est possible d'afficher le contenu du BAR (bank address registers).

Pour ce qui de la gestion de la prochaine tache à exécuter il y a possibilité de faire en sorte que notre composant:
-changer la priorité du master sur le bus AMBA
-empêcher l'accès en dur en modifiant le comportement du contrôleur de bus (1).

(1): Ceci ne fonctionnera que si les taches sont sur des partitions différentes et sur des processeurs indépendants.

Afin de réaliser le composant, il est envisageable de l'intégrer directement au sein du contrôleur de mémoire.

Celui devra donc récupérer le contenu des caches des processeurs afin de déterminé quel programme et en exécution.

=== Bibliographie: ===

[1] lien site gaisler
gaisler.com/index.php

[2] lien vers GRLIB IP Library User’s Manual
http://www.gaisler.com/products/grlib/grlib.pdf

[3] lien vers LEON3 GR-XC3S-1500 Template Design
http://www.gaisler.com/products/grlib/grip.pdf

P37 Creation d'un composant d'audit des accès cache mémoire sur un microprocesseur LEON3 simulé en FPGA

2014-11-09T21:27:54Z

Jvaessen : ajout de la semaine 6

= Presentation du projet =

Ce projet s'inscrit dans l'amélioration d'une solution d'IP pour un SoftCore implanté dans un FPGA.

== Cahier des charges ==

Il faudra créer un composant VHDL capable de:

1.
sniffer les paquets à destination de la SDRAM/RAM (via le memory controler)

2.
Vérifier le contenu du paquet savoir, le type d'accès (lecture/écriture) de la mémoire

3.
compter le nombre d'accès mémoire en écriture

4.
Différencier les zones mémoires qui sont accéder afin de déterminer l'application/taches qui est à l'origine.

Il faudra aussi, faire cohabiter deux (ou plus) SoftCore Leon3 communicants sur le même bus AMBA.

== Planning: ==

=== Semaine 1: ===
Décourverte de l'équipe et discussion concernant le projet

=== Semaine 2: ===
Mise en place des outils (cygwin64 avec "développement") et discussion concernant les possibilités offertes concernant le bus AMBA

=== Semaine 3: ===
Après plusieurs essais d'utilisation des paquets tcl/tk fournis avec cygwin, nous nous sommes aperçus que l'environnement cygwin ne semble pas utilisable pour le projet.
C'est pour cela que nous passons à une autre solution ie Msys cependant nous sommes en train de faire en sorte d'avoir la bonne version des outils TCL/TK.

=== Semaine 4: ===
Mise en place d'un SoftCore Leon3 sur un FPGA, exploration des modifications à apporter afin d'implémenter deux softcores avec un cache L2C.

=== Semaine 5: ===

Mise en place de multiple SoftCore Leon3 sur un FPGA, exploration des modifications à apporter afin d'implémenter deux softcores avec un cache L2C.

=== Semaine 6: ===

Abandon du cache L2C (composant manquant).

Compilation d'un "hello world" avec les outils et paramètres adéquats pour une architecture multicoeur.

Épluchage des documentations afin d'établir les signaux pertinents pour réaliser des compteurs qui auront les caractéristiques suivantes:

-une paire de compteurs pour la lecture et l'écriture en mémoire

-3 paire de compteur (PROM, RAM et SDRAM).

== Annexes: ==

=== Notes: ===
D'après la section 2.15 [3], on a la correspondance suivante:
GRLIB IP Cores
Core Vendor
LEON3|0x01 (ie Gaisler Research [2] p49)
MCTRL|0x04 (ie European Space Agency [2]p49)
Ce qui nous permettra d'identifier le contrôleur mémoire

Voici quelques suggestions que l'on peut faire concernant le sniffeur de paquets:

Pour cela on utilise très largement le document [2] (GRLIB IP Library User’s Manual)

Lors d'une simulation du code VHDL, il est possible d'afficher le contenu du BAR (bank address registers).

Pour ce qui de la gestion de la prochaine tache à exécuter il y a possibilité de faire en sorte que notre composant:
-changer la priorité du master sur le bus AMBA
-empêcher l'accès en dur en modifiant le comportement du contrôleur de bus (1).

(1): Ceci ne fonctionnera que si les taches sont sur des partitions différentes et sur des processeurs indépendants.

Afin de réaliser le composant, il est envisageable de l'intégrer directement au sein du contrôleur de mémoire.

Celui devra donc récupérer le contenu des caches des processeurs afin de déterminé quel programme et en exécution.

=== Bibliographie: ===

[1] lien site gaisler
gaisler.com/index.php

[2] lien vers GRLIB IP Library User’s Manual
http://www.gaisler.com/products/grlib/grlib.pdf

[3] lien vers LEON3 GR-XC3S-1500 Template Design
http://www.gaisler.com/products/grlib/grip.pdf

P37 Creation d'un composant d'audit des accès cache mémoire sur un microprocesseur LEON3 simulé en FPGA

2014-10-20T20:11:26Z

Jvaessen : /* Semaine 4: */

P37 Creation d'un composant d'audit des accès cache mémoire sur un microprocesseur LEON3 simulé en FPGA

2014-10-11T07:48:37Z

Jvaessen : /* Cahier des charges */

P37 Creation d'un composant d'audit des accès cache mémoire sur un microprocesseur LEON3 simulé en FPGA

2014-10-11T07:37:35Z

Jvaessen : Page créée avec « = Presentation du projet = Ce projet s'inscrit dans l'amélioration d'une solution d'IP pour un SoftCore implanté dans un FPGA. == Cahier des charges == Il faudra créer... »

Projets IMA5 2014/2015

2014-10-11T07:31:53Z

Jvaessen : /* Répartition des binômes */

Modem pour le numérique

2014-04-15T20:19:56Z

Jvaessen : /* 10éme semaine: (du 07/04/2014 au 10/04/2014) */

= Modulateur et démodulateur pour communications numériques =

== Cahier des charges ==

=== Présentation générale du projet ===

Dans le cadre des TPs d'électronique et de transmission RF, nous avons découvert qu'il existe plusieurs modes de modulation, pour transmettre un signal modulant.

Celles vues en TP au S7 sont la modulation en amplitude, en fréquence, en phase, en BPSK et en QPSK.

Or les modulations en phase, en fréquence et en amplitude étant celles les plus connues, la modulation en QAM (Modulation d'Amplitude en Quadrature) est quant à elle moins connue, mais tout aussi utilisées:

-pour la TNT en 64 QAM (en France).

[[Fichier:P34_2013_2014_64qam.jpg|300px|thumb|center|Exemple de constellation 64QAM.]]

-pour le WiFi en 64-QAM ou 256-QAM (à vérifier).

Or ces deux dernières étant peu représentées au niveau des travaux pratiques, ce projet permettra de fournir un peu plus de pratique sur les modulations de type QAM (en diagramme I/Q) dans le domaine des radiofréquences (~800MHz).

(Le nombre devant le QAM indique le nombre de points dans le diagramme I/Q qu'on appelle aussi constellation)

On se réserve le droit de faire '''évoluer''' le cahier des charges a posteriori, si certaines contraintes étaient amenées à évoluer ou se préciser.

=== Objectif et intérêt du projet ===

Pour cela, on nous a fourni des modules commerciaux Mini-circuit pouvant travailler dans les radios-fréquences.

Ceux-ci permettront de mettre en place une grande partie de la chaine de transmission (voir schéma de la chaine de transmission).

[[Fichier:P34_2013_2014_Chaine_modulation.PNG|300px|thumb|center|Modulation.]]

[[Fichier:P34_2013_2014_Chaine_demodulation.PNG|300px|thumb|center|Démodulation.]]

On a tout d'abord à mettre en place une carte FPGA et/ou un dispositif permettant d'envoyer un flux de données numériques continuellement pour pouvoir visualiser le diagramme I/Q (mise en valeur du diagramme I/Q et voir même un diagramme un peu plus complexe que le BPSK ou le QPSK).

Le canal de transmission qui sera un simple fil électrique, mais pourra devenir une antenne réceptrice et émettrice si le temps imparti le permet (mise en valeur du et mesure du Bit Error Rate qui sera bien sûr différent suivant le canal de transmission).

Du côté réception ,après démodulation du signal, une remise en forme et une interprétation des données seront réalisées, celle-ci dépendra bien entendu de la provenance du flux de données (constater le succès ou l'échec d'un envoi de données).

Enfin si le temps le permets on pourra mettre en une place un système de codage de l'information avec par exemple un codage redondant permettant de corrigé l'erreur (À définir, on pourra faire constater l'efficacité d'une méthode de codage au choix).

=== Étapes/Déroulement du projet ===

De même que pour le cahier des charges, il se peut que les étapes diffèrent plus ou moins, en fonction des disponibilités, matérielles et contraintes.

==== => Caractérisation des blocs Mini-circuits et épluchage des documentations techniques====
Avant de les utiliser dans la chaine de transmission, nous avons à faire une caractérisation des blocs fournis:

-la caractérisation du VCO.

-l'étude des possibilités offerte par le modulateur (cela déterminera le nombre de points possible dans la constellation, ie savoir si l'on peut aller au-delà de la QPSK).

-la caractérisation des mélangeurs (Mixer), leurs facteurs réels de multiplication.

==== => Utilisation et exploitation des caractérisations ====
On pourra ensuite trouver les paramètres pour régler correctement dans notre chaine de transmission certains de nos sous-systèmes comme la boucle à verrouillage de phase.

==== => Génération d'un flux des données numériques ====
Comme dit précédemment, l'idéal et d'avoir un flux de données numériques transmis en permanence.
Pour cela plusieurs solutions s'offre à nous, on pourra utiliser un montage générateur pseudo aléatoire (un circuit que l'on a fait l'année dernière en Conception de Circuit Électronique).
On pourra "émuler" ce montage avec un Arduino, ou bien même le faire au moyen de la Nanoboard.
On pourra aussi transmettre des chaines de caractère en continu.

==== => Test de la chaine ====
Une fois les étapes précédentes réalisées, on pourra passer au test de la chaine de transmission. Il faudra vérifier le bon fonctionnement en aval, dedans (boucle à verrouillage de phase), et en amont de la chaine de transmission.

==== => Première mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.
Il est possible que la conception d'un dispositif soit nécessaire que ce soit pour les deux mesures du B.E.R..

==== => Antennes ====
Si toutes les étapes précédentes sont satisfaites, on pourra alors faire un canal de transmission plus intéressant, à savoir l'air.
Nous passerons alors à la conception des antennes, émettrice et réceptrice.

==== => Deuxième mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.

==== => Codage de l'information et correction d'erreur ====
En toute fin de ce projet, on pourra même mettre deux dispositifs en aval et en amont de la chaine de transmission.
On réalisera alors un codeur et un décodeur permettant de faire de la détection/correction d'erreur.

==== => Mise en place d'outil de débogage (tout au long)====
La mise en place de simples outils de débogage et primordiale, ceux-ci permettront de vérifier le bon fonctionnement de la chaine.

==== => Proposition d'un sujet de TP (tout au long) ====
Il se trouve que lors du déroulement du projet, on pourra être amené à se poser des questions au niveau des réglages de la chaine de transmission.
Or il est fort probable que les élèves qui travailleront sur ce TP pourront alors se poser les mêmes questions.
C'est pour cela qui sera judicieux de prendre soin de noter les problématiques rencontrées et de donner un certain fil de développement pour venir à bout de la problématique posée.
Ce qui reviendra à proposer des axes/questions sur les manipulations de cette maquette de TP.

== Note valable pour toutes les semaines ==

'''[[Si un point vous semble imprécis, veuillez vous reporter aux détails fournis en annexe.]]'''

== 1éme semaine: (du 27/01/2014 au 01/02/2014) ==

Séance du 05/02/2014 :

Pour bien comprendre les différentes choses à réaliser, on a refait les manipulations vues en TP. On a, pour cela utiliser la maquette didactique TIMS pour générer différent type de modulation:

-la modulation en 4,8,16PSK (on obtient une constellation en forme de cercle).

-La modulation en 4,8,16QAM (on obtient une constellation avec un carré, ou deux: de différentes tailles).

On a très vite dégagé la nécessité de réaliser un montage générateur de tous les mots numériques possibles.
On a donc fait un programme sur arduino qui équivaut au générateur pseudo aléatoire.
Celui-ci est directement inspiré du montage que l'on a réalisé l'année dernière en conception de circuit électronique.

Séance du 06/02/2014 :

Lors de cette séance on a exploré toutes les possibilités concernant la communication entre la maquette/carte, car cela pour avoir une influence non négligeable sur le choix de la carte F.P.G.A. et du design de la maquette.

On a donc aussi fait des recherches concernant les possibilités de communications et les blocs I.P. (Intellectual Properties) permettant de programmer un F.P.G.A.

Et enfin, on a eu une discussion avec un responsable technique pour ce qui de la C.E.M. (Compatibilité Electro-Magnétique)

== 2éme semaine: (du 03/02/2014 au 08/02/2014) ==

Réflexion sur les possibilités possibles et offertes par le sujet pour ce qui est des parties de communications entre la maquette en interne et de son environnement.

[[Fichier:P34_2013_2014_schéma_principe_carte_semaine_2.PNG|300px|thumb|center|Maquette en interne/externe.]]

N'ayant jamais utilisé d'autre carte que la Nanoboard, on s'est attelé à faire des recherches sur la manière de procéder pour programmer une carte F.P.G.A., il se trouve que chaque carte de développement à ses propres manières pour être programmé.

On a pris le soin de noter toutes les questions concernant le F.P.G.A. pour un intervenant industriel qui assura un cours la semaine prochaine.

== 3éme semaine: (du 10/02/2014 au 15/02/2014) ==

Ayant les oscillateurs commandables en tension, on a pu commencer à faire une manipulation avec les composants Mini-Circuit.

Mais après un problème suite à une manipulation l'un des VCOs ne fonctionne plus.

Ce qui nous amène à penser qu'il sera judicieux de prévoir une alimentation au niveau de la carte.

Celle-ci devra être inférieure ou égale à la tension maximale d'alimentation du composant (ceux-ci étant très sensible).

Questions/Réponses:

Comment fait-on pour programmer une carte F.P.G.A. est-ce que la programmation se fait "in situe" ? (in situe : c'est à dire sur la carte elle-même)
Oui, c'est ce qui est utilisé, via un câble JTAG.

Est-ce possible faire une interface USB pour permettre à un ordinateur de communiquer avec la maquette/carte via un F.P.G.A. ? Oui.

Est-ce que la gestion de l'interface Ethernet est envisageable ? Oui.

Pour une communication en protocole UDP avec un ordinateur via une liaison Ethernet, est-ce qu'il y a d'autres façons que d'utiliser un "SoftCore" ?

Oui, il existe aussi bien en Software, qu'en Hardware.

== 4éme semaine: (du 17/02/2014 au 22/02/2014) ==

On a donc repris l'idée de la 2éme semaine.

Après avoir mis en place un cahier des charges au niveau des qualités, bande passante minimale.

Nous avons fait des recherches sur les composants à utiliser (i.e. CAN, CAN, ...)

Ce qui nous a permis après une édition rapide de schéma électrique (schematic) d'avoir une idée du nombre de pins dont nous aurons besoin sur une carte FPGA afin de réaliser le projet.

Après prospection, il se trouve que nous nous dirigerions vers la carte Digilent Spartan 3, dont l'école était déjà en possession.

Donc nous nous sommes attelés à faire des recherches et des essais sur cette carte et pour notamment trouver un moyen de la faire fonctionner.

== 5éme semaine: (du 03/03/2014 au 08/03/2014) ==

Tout d'abord, après plusieurs heures de recherches et d'essai infructueux, on a fini par trouver les drivers pour le câble USB diligent.

Et donc ainsi avoir un fonctionnement de la communication via le câble JTAG plus propice au fonctionnement de la carte.

On a pu enfin se conforter sur une partie des composants et des dimensionnements pour certains d'entre eux (valeur de résistance,capacité...)

Schématics: Édition de multiple bibliothèque pour Altium, intégrant à la fois schématics et leur empreinte PCB associée.

(On a pu constater qu'une interface 3v3 5v n'est pas forcement nécessaire pour assurer le bon fonctionnement entre deux cartes avec des tensions d'alimentation différentes.)

== 6éme semaine: (du 10/03/2014 au 15/03/2014) ==

On a pu enfin se conforter sur l'ensemble des composants et des choix de régulateur et utilisation d'autre diode Zener.

On trouvera le schéma intégral avec les bibliothèques nécessaires dans la semaine 5.

Cette semaine a été dédiée à l'envoi de la commande des composants au sein du magasin de l'école et du fournisseur.

Après envoi de la commande, il se trouve que le projet a changé d'objectif principal.

Il est maintenant prioritaire de réaliser un code VHDL capable d'évaluer la vitesse de transmission numérique du côté récepteur.

== 7éme semaine: (du 17/03/2014 au 22/03/2014) ==

Pour cette semaine, on s'est concentré sur la réalisation d'un générateur pseudo aléatoire en interne au FPGA.

On réalisera une échelle de résistance afin de réaliser une conversion numérique analogique afin de l'envoyer sur la chaine de transmission.

Ce code de "base" nous permettra de réaliser un flux de données fictif pour obtenir toutes les combinaisons récupérant le résultat du bus.

[[MédiaP34_2013_2014_gene_pseudo_19_03_2014_6_semaine_7.zip|Archive contenant le projet ISE Xilinx.]]

[[Fichier:P34_2013_2014_rtl_semaine_7.PNG|300px|thumb|center|extrait du schéma RTL, on peut y voir clairement les inférences de Xilinx.]]

Ce schéma a deux entrées et une sortie, une entrée d'initialisation, une horloge et une sortie pour la trame en pseudo aléatoire.

On fera l'essai sur la carte lors de la semaine suivante.

== 8éme semaine: (du 24/03/2014 au 26/03/2014) ==

Après le premier test, on pourrait penser que l'on récupère du bruit en sortie de la carte:

[[Fichier:P34_2013_2014_DSC_0024_1_probleme_d_overshoot_semaine_8.jpg|300px|thumb|center|Overshoot.]]

Pour pouvoir remédier à ce problème, on a fait une prédivision de l'horloge

[[Fichier:P34_2013_2014_DSC_0037_1_div_freq_semaine_8.jpg|300px|thumb|center|Overshoot après division.]]

[[Fichier:P34_2013_2014_DSC_0039_1_div_freq_zoom_semaine_8.jpg|300px|thumb|center|Overshoot après division (Zoom).]]

Archive contenant toutes les modifications:

[[Média:P34_2013_2014_gene_pseudo_26_03_2014_2_semaine_8.zip|VHDL Semaine 8.]]

On a trouvé un moyen de faire un CNA facilement, via une "échelle dite R-2R". [[http://www.uchobby.com/index.php/2008/01/08/arduino-audio-dac-options/|Pour le réseau R 2R.]]

Il faut encore modifier le VHDL pour pouvoir l'exploiter et ainsi générer une constellation.

== 9éme semaine: (du 28/03/2014 au 03/04/2014) ==

On a pris donc le soin de modifier le VHDL:

[[Média:P34_2013_2014_gene_pseudo_31_03_2014_1_semaine_9.zip|VHDL semaine 9]]

Ce VHDL à été mis à jour, avec deux entrées (initialisation et une horloge) et un bus de sortie (8 bits), avec les trames pseudoaléatoires.

On envoie ces signaux sur deux C.N.A.s (4 bits chacun) pour générer deux signaux I et Q, on peut voir une constellation se dessiner en mode X-Y.

[[Fichier:P34_2013_2014_DSC_0072_1_Montage_entier_4qam_semaine_9.jpg|300px|thumb|center|Montage avec constellations 4QAM.]]

D'autres constellations réalisées sont disponibles en annexe. On peut monter jusqu'à une constellation de 256 points (2^4*2^4).

On a réalisé le montage complet de toute la chaine de transmission. Il se trouve que la Boucle à Verrouillage de Phase (ou appellée PLL, Phase Loop Locker) ne se verrouille pas sur la porteuse du signal que l'on souhaite récupéré, de ce fait on ne peut pas récupérer les signaux I et Q.

== 10éme semaine: (du 07/04/2014 au 10/04/2014) ==

On a réalisé le montage que l'on évoquait en semaine 9:

[[Fichier:P34_2013_2014_DSC_0027_montage_realisee_semaine_10.jpg|center|thumb|300px|Montage pour améliorer la PLL.]]

Il se trouve qu’après un réglage précis de la tension d'offset permettant d'être un proche de la fréquence à capturer on obtient:

[[Fichier:P34_2013_2014_DSC_0025_PLL_non_verrouillage_semaine_10.jpg|center|thumb|300px|Signaux I/Q après ajout du montage.]]

Pour ce qui des axes d'amélioration et de développement, on pourra proposer:

-Améliorer la P.L.L.

-Écrire le VHDL permettant de faire la remise en forme en utilisant un montage simplifié de la chaine de transmission

-Réaliser la carte

Liens pour la P.L.L.:

http://en.wikipedia.org/wiki/Phase-locked_loop

http://fr.wikipedia.org/wiki/Boucle_%C3%A0_phase_asservie

== Conclusion: ==

Ce projet intéressant m'a permis de prendre conscience les différences fondamentales entre la théorie et la pratique. Cela m'a permis de prendre conscience que faut toujours avoir un esprit critique envers la théorie, car il faut savoir découvrir l'origine du problème en cas de dysfonctionnement, car le travail d'un ingénieur ne se limite pas à fournir des solutions.

Mon projet scolaire s'est donc achevé à ce point, cependant d'autres élèves pourront prendre le relais en réalisant la carte correspondant au schéma et ainsi réaliser rapidement l'interface entre la carte FPGA et la maquette. Et pourront se concentrer sur la mise en route intégrale de la chaine.

= Annexes =

== Annexe A: Détails techniques des semaines ==

=== 1éme semaine: (du 27/01/2014 au 01/02/2014) ===

Après on a réfléchi sur la potentielle conception/utilisation d'une carte FPGA.
Il sera judicieux de ne pas se précipiter sur le schéma et la conception/utilisation d'une carte FPGA, sans avoir, au préalable fait le VHDL et le testez avec un banc de test virtuel.
L'intérêt et de mettre en valeur la nécessité ou non de certains signaux pour le schéma de la carte.
On va mettre en oeuvre les connaissances acquises au S7 en VHDL (en TP de Circuit Numérique Programmble).

Pour ce qui est de l'Arduino, on a répondu aux interrogations suivantes (certaines de ces questions paraissent triviales, mais on préfère éviter les surprises):

Quelle est la vitesse maximale de la communication série de l'Arduino ?
-115200bauds

Est-ce que, un programme de type "Analog Write" est-il une vraie sortie analogique ?

-Non, c'est juste une PWM. Elle sera exploitable pour faire les signales I/Q mais très contraignantes, car il faudra filtré le signal, et ce sera beaucoup trop lent (du au fait que la modulation est faite au alentour de 850Mhz), le FPGA sera un passage obligé cela ouvrira les portes d'un plus grand débit.

==== Manipulation réalisée sur la maquette TIMS : ====

On a fait un des montages présentés dans l'ouvrage "Volume D1 Fundamental Digital Experiments" dans le but de visualiser l’objectif à atteindre.

On obtient la constellation suivante (16QAM):

[[Fichier:P34_2013_2014_constelation_tims_semaine_1.PNG|300px|thumb|center|Constellation visualisée en mode X-Y.]]

Ce qui correspond à deux signaux en visualisation temporelle de cette forme :

[[Fichier:P34_2013_2014_constelation_temporelle_tims_semaine_1.PNG|300px|thumb|center|Signaux I et Q. (Image très floutée, à remplacer)]]

On pourra facilement obtenir le même résultat en générant un bus de trame pseudo aléatoire et en l'injectant dans un C.N.A. (Conversion Numérique Analogique)

==== Code Arduino réalisé: ====

[[Fichier:P34_2013_2014_schema_electronique_generateur_pseudo_aleatoire.png|300px|thumb|center|Schéma électronique du générateur pseudo aléatoire.]]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_chrono_simule.PNG|300px|thumb|center|Résultat de la simulation du générateur pseudo aléatoire (on a eu la même chose en pratique).]]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_arduino.jpg|300px|thumb|center|Resultat avec le générateur pseudo aléatoire "émuler" avec l'Arduino.]]

Comparaison carte réelle/résultat Arduino:

C'était exactement les signaux attendus (même s'il y un décalage a par rapport à l'original).

On aura bien pour une QPSK (4PSK) tous les couples (ie 00,01,11 et 10).

À propos de l'arduino, on pourra envisager une amélioration pour générer une séquence plus longue:

-il faudra simplement utiliser un tableau d'entier.

-paramétrer sa taille avec un N par exemple.

-N correspondra à la taille de séquence de longueur 2^N.

Voir la section "Code Arduino réalisé" en annexe B dans la semaine correspondante.

==== Possibilités de communications: ====

Exploration des possibilités de communication entre le PC et la carte en amont:

=====-> Ethernet: =====

*+ Vitesse de transmission (~10M-100M-G)bauds

*- La gestion du flux de données doit être faite par un microcontrôleur (celui-ci pourra être implémenté un bloc I.P. à l'intérieur du FPGA)

-> - Haute consommation de CLB du FPGA.

=====-> SPI (communication série): =====

*- Vitesse de transmission

-> Arduino capable de communiquer jusqu'a 115200 bauds

-> D'après certaines discussions sur des forums, on pourrait « pousser » au-delà.

=====-> I2C : =====

Communication abandonnée, ce n'est pas une priorité.

==== À propos des blocs I.P.: ====

En consultant les ordinateurs et en s'appuyant des T.P.s de CNP, on constate que les blocs suivants existent:

- Xilinx Microblaze/Xilinx Power PC ("µP FPGA")

-> Est-ce possible d'utiliser ces blocs I.P. pour programmer un FPGA sur une carte autre que la Nanoboard ? Comment ?

- EMACx (Ethernet Media Acess Control)(:lien physique entre processeurs et "standart Physical Layer device IEEE802.3")

===== Conception de la carte: =====

L'idéal est de se documenter sur la Compatibilité électromagnétique.

=== 2éme semaine: (du 03/02/2014 au 08/02/2014) ===

(Rien pour l'annexe.)

=== 3éme semaine: (du 10/02/2014 au 15/02/2014) ===

Lors de cette semaine, après avoir eu le problème de manipulation, nous avons pu prendre connaissance d'un certain montage qui s’avéra utile pour la conception de la carte/maquette.

[[Fichier:P34_2013_2014_schéma_limiteur_de_courant_semaine_3.PNG|300px|thumb|center|Schéma limiteur de courant.]]

On remarquera que ce montage se retrouve dans la partie "typical application" de la documentation technique du 7805.

=== 4éme semaine: (du 17/02/2014 au 22/02/2014) ===

On souhaite pouvoir réaliser une communication unidirectionnelle ou même transmettre un signal audio ce qui nous contraint à une bande passante minimale de 48kHz, on prendra 200kHz (pour être bien au-delà de la condition du théorème de Shannon): le but serait donc de brancher par exemple une source audio quelconque puis de la transmettre à travers la maquette et de la recomposer en fin de chaine.

Après édition rapide du schéma, on en dégage qu'il nous faudra un minimum d'environ 50 entrées/sorties. Mais ceci ce nombre sera très probablement revu à la hausse lors de prochaine séance.

Voici la carte que l'on utilisera dans la suite du projet:

[[Fichier:P34_2013_2014_S3BOARD-top-400_semaine_4.gif|300px|thumb|center|Digilent Spartan 3.]]

=== 5éme semaine: (du 03/03/2014 au 08/03/2014) ===

Lien vers le Design complet avec les librairies incluses (on remarquera qu'il serait judicieux d’installer toutes les librairies avant d’essayer d'ouvrir le schéma)

A notez aussi que l'on trouvera des reliques de feuilles Excel permettant de trouver rapidement des ratios dans la série E12.

[[Média:P34_2013_2014_Design_pcb_plus_librairies_semaine_5_6.zip|Schéma + Bibliothèques.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.pdf|Schéma en PDF.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.png|Schéma au format A2.]]

=== 6éme semaine: (du 10/03/2014 au 15/03/2014) ===

(Rien pour l'annexe.)

=== 7éme semaine: (du 17/03/2014 au 22/03/2014) ===

(Rien pour l'annexe.)

=== 8éme semaine: (du 24/03/2014 au 26/03/2014) ===

(Rien pour l'annexe.)

=== 9éme semaine: (du 28/03/2014 au 03/04/2014) ===

[[Fichier:P34_2013_2014_DSC_0061_1_r_2r_semaine_9.jpg|center|thumb|300px|Le réseau R-2R.]]

[[Fichier:P34_2013_2014_DSC_0062_1_4QAM_semaine_9.jpg|center|thumb|300px|4QAM.]]

[[Fichier:P34_2013_2014_DSC_0066_1_16QAM_semaine_9.jpg|center|thumb|300px|16QAM.]]

[[Fichier:P34_2013_2014_DSC_0069_1_64QAM_semaine_9.jpg|center|thumb|300px|64QAM.]]

Pas de photos pour la constellation à 256 points, mais elle a été réalisée.

Pour ce qui est du montage, malgré que la P.L.L., on a un signal d'erreur après filtrage :

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Chaine 1: Vtune (commande du V.C.O.)/Chaine 2: "erreur" de commande]]

Ce qui met en valeur immédiatement deux problèmes majeurs:

La chaine fonctionne sur le papier, mais lors de sa mise en pratique, il faut penser à mettre une tension d'offset et aussi réaliser une amplification de l'erreur pour avoir des grandeurs de commande adaptée au Vtune du V.C.O..

On propose l'amélioration suivante (qui sera réalisé à la prochaine séance):

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Proposition de voie d'amélioration.]]

On remarquera que les valeurs des résistances et des capacités on était choisi pour permettre un fonctionnement correct des A.O. (Amplificateur Opérationnel), mais pas pour ce qui de l'asservissement de la boucle par manque de temps.

A la fin de cette, on a eu à démonter le montage à cause de contraintes concernant les Mini-circuits (car utilisé en travaux pratiques).

=== 10éme semaine: (du 07/04/2014 au 10/04/2014) ===

Spectres des signaux de la chaine de transmission:

[[Fichier:P34_2013_2014_DSC_0001_allure_spectre_reception_semaine_10.jpg|center|thumb|300px|Spectre en réception.]]

Porteuse utilisée pour la modulation I/Q à environ 60MHz.

Porteuse utilisée pour le transport en fréquence à environ 810MHz:

[[Fichier:P34_2013_2014_DSC_0035_constellation_recupere_PLL_NV_semaine_10.jpg|center|thumb|300px|"Constellation" récupérée avec la PLL défectueuse (on souhaite se verrouiller sur la raie à 868MHz).]]

Question en suspens: faudrait-il utiliser un filtre passe-bande incluant 868Mhz pour pouvoir se verrouiller sur cette fréquence ?

On remarquera le fait que l'oscillateur du côté de la chaine d'émission a d'importantes non-linéarités (on peut observer à l'analyseur de spectre 3 à 4 raies aux fréquences multiples).

Ce qui donne un diagramme de constellation plutôt mauvais si l'on fait le montage suivant:

[[Fichier:P34_2013_2014_montage_non_linearite_vco_constellation_semaine_10.PNG|center|thumb|300px|Montage réalisée.]]

[[Fichier:P34_2013_2014_sortie_montage_non_linearite_semaine_10.PNG|center|thumb|300px|La constellation 4QAM est attendue, on est loin du résultat attendu (aucune photo n'a était réalisé d'ou le dessin).]]

== Annexe B: Digilent Spartan 3 ==

=== Procédure pour faire fonctionner la carte Digilent Spartan 3: ===

Ne connectez pas de connecteur JTAG pendant les installations. Redémarrez après chaque installation.

Tout d'abord, il faut savoir que le l'ISE Webpack 14.6 fonctionne avec la carte (n'utilisez pas la 14.7, elle ne supporte pas la génération spartan 3 !):

Installez donc l'ISE WebPack 14.6 (ou antérieur à condition que celle-ci soit supérieur à la 7.1i (d'après leur documentation))

(voir lien utile sur Xilinx)

Une fois l'installation de l'ISE terminé, faites en sorte d'avoir celui que soit opérationnel (la licence est gratuite !).

Installez la "library" ADEPT 2.3 voir le lien utile.

Après vous n'avez plus qu'a utilisez ISE Xilinx normalement et vous serez capable de reconnaitre la carte via la liaison JTAG, et de le programmer.

=== Liens utiles: ===

Lien constructeur/vendeur (avec ressources utiles en bas de la page):

http://www.digilentinc.com/Products/Detail.cfm?Prod=S3BOARD

Lien "Library" pour le câble USB digilent:

http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,66,69&Prod=ADEPT

Lien Xilinx (Pour l'ISE 14.6):

http://www.xilinx.com/products/design-tools/ise-design-suite/index.htm

Lien Xilinx (Pour les versions antérieures veuillez faire attention au système d'exploitation, votre architecture matérielle et le FPGA cible):

(Les informations de compatibilité son sur la page suivante:) (mots clés: xilinx classic(s))

http://www.xilinx.com/tools/classics.htm

=== Procédure pour faire une programmation en volatile: ===

Générer le bitstream, et le charger.

=== Procédure pour faire une programmation en "non"-volatile: ===

Générer le bitstream et l'utiliser pour générer un .mcs qui vous permettra d'inscrire le programme dans la mémoire (E?)PROM.

On remarquera que la programmation en non volatile est utile pour faire un remise à zéro et recharger le contenu de l'(E?)PROM, mais semble être sensible au débranchement de l'adaptateur d'alimentation de la carte.

=== Exemple de programmation: ===

Voir le lien digilent pour ceci dans cette annexe.

= Fichiers Rendus =

Rapport projet numéro 34 VAESSEN :[[Fichier:Rapport_projet_p34_s8_6.pdf]]

Source VHDL Final :[[Fichier:P34_2013_2014_gene_pseudo_31_03_2014_1_semaine_9.zip]]

Code Arduino :[[Fichier:P34_2013_204_Generateur_pseudo.zip]]

Design sous Altium :[[Fichier:P34_2013_2014_Design_pcb_plus_librairies_semaine_5_6.zip]]

Modem pour le numérique

2014-04-15T08:23:26Z

Jvaessen : /* 10éme semaine: (du 07/04/2014 au 10/04/2014) */

= Modulateur et démodulateur pour communications numériques =

== Cahier des charges ==

=== Présentation générale du projet ===

Dans le cadre des TPs d'électronique et de transmission RF, nous avons découvert qu'il existe plusieurs modes de modulation, pour transmettre un signal modulant.

Celles vues en TP au S7 sont la modulation en amplitude, en fréquence, en phase, en BPSK et en QPSK.

Or les modulations en phase, en fréquence et en amplitude étant celles les plus connues, la modulation en QAM (Modulation d'Amplitude en Quadrature) est quant à elle moins connue, mais tout aussi utilisées:

-pour la TNT en 64 QAM (en France).

[[Fichier:P34_2013_2014_64qam.jpg|300px|thumb|center|Exemple de constellation 64QAM.]]

-pour le WiFi en 64-QAM ou 256-QAM (à vérifier).

Or ces deux dernières étant peu représentées au niveau des travaux pratiques, ce projet permettra de fournir un peu plus de pratique sur les modulations de type QAM (en diagramme I/Q) dans le domaine des radiofréquences (~800MHz).

(Le nombre devant le QAM indique le nombre de points dans le diagramme I/Q qu'on appelle aussi constellation)

On se réserve le droit de faire '''évoluer''' le cahier des charges a posteriori, si certaines contraintes étaient amenées à évoluer ou se préciser.

=== Objectif et intérêt du projet ===

Pour cela, on nous a fourni des modules commerciaux Mini-circuit pouvant travailler dans les radios-fréquences.

Ceux-ci permettront de mettre en place une grande partie de la chaine de transmission (voir schéma de la chaine de transmission).

[[Fichier:P34_2013_2014_Chaine_modulation.PNG|300px|thumb|center|Modulation.]]

[[Fichier:P34_2013_2014_Chaine_demodulation.PNG|300px|thumb|center|Démodulation.]]

On a tout d'abord à mettre en place une carte FPGA et/ou un dispositif permettant d'envoyer un flux de données numériques continuellement pour pouvoir visualiser le diagramme I/Q (mise en valeur du diagramme I/Q et voir même un diagramme un peu plus complexe que le BPSK ou le QPSK).

Le canal de transmission qui sera un simple fil électrique, mais pourra devenir une antenne réceptrice et émettrice si le temps imparti le permet (mise en valeur du et mesure du Bit Error Rate qui sera bien sûr différent suivant le canal de transmission).

Du côté réception ,après démodulation du signal, une remise en forme et une interprétation des données seront réalisées, celle-ci dépendra bien entendu de la provenance du flux de données (constater le succès ou l'échec d'un envoi de données).

Enfin si le temps le permets on pourra mettre en une place un système de codage de l'information avec par exemple un codage redondant permettant de corrigé l'erreur (À définir, on pourra faire constater l'efficacité d'une méthode de codage au choix).

=== Étapes/Déroulement du projet ===

De même que pour le cahier des charges, il se peut que les étapes diffèrent plus ou moins, en fonction des disponibilités, matérielles et contraintes.

==== => Caractérisation des blocs Mini-circuits et épluchage des documentations techniques====
Avant de les utiliser dans la chaine de transmission, nous avons à faire une caractérisation des blocs fournis:

-la caractérisation du VCO.

-l'étude des possibilités offerte par le modulateur (cela déterminera le nombre de points possible dans la constellation, ie savoir si l'on peut aller au-delà de la QPSK).

-la caractérisation des mélangeurs (Mixer), leurs facteurs réels de multiplication.

==== => Utilisation et exploitation des caractérisations ====
On pourra ensuite trouver les paramètres pour régler correctement dans notre chaine de transmission certains de nos sous-systèmes comme la boucle à verrouillage de phase.

==== => Génération d'un flux des données numériques ====
Comme dit précédemment, l'idéal et d'avoir un flux de données numériques transmis en permanence.
Pour cela plusieurs solutions s'offre à nous, on pourra utiliser un montage générateur pseudo aléatoire (un circuit que l'on a fait l'année dernière en Conception de Circuit Électronique).
On pourra "émuler" ce montage avec un Arduino, ou bien même le faire au moyen de la Nanoboard.
On pourra aussi transmettre des chaines de caractère en continu.

==== => Test de la chaine ====
Une fois les étapes précédentes réalisées, on pourra passer au test de la chaine de transmission. Il faudra vérifier le bon fonctionnement en aval, dedans (boucle à verrouillage de phase), et en amont de la chaine de transmission.

==== => Première mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.
Il est possible que la conception d'un dispositif soit nécessaire que ce soit pour les deux mesures du B.E.R..

==== => Antennes ====
Si toutes les étapes précédentes sont satisfaites, on pourra alors faire un canal de transmission plus intéressant, à savoir l'air.
Nous passerons alors à la conception des antennes, émettrice et réceptrice.

==== => Deuxième mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.

==== => Codage de l'information et correction d'erreur ====
En toute fin de ce projet, on pourra même mettre deux dispositifs en aval et en amont de la chaine de transmission.
On réalisera alors un codeur et un décodeur permettant de faire de la détection/correction d'erreur.

==== => Mise en place d'outil de débogage (tout au long)====
La mise en place de simples outils de débogage et primordiale, ceux-ci permettront de vérifier le bon fonctionnement de la chaine.

==== => Proposition d'un sujet de TP (tout au long) ====
Il se trouve que lors du déroulement du projet, on pourra être amené à se poser des questions au niveau des réglages de la chaine de transmission.
Or il est fort probable que les élèves qui travailleront sur ce TP pourront alors se poser les mêmes questions.
C'est pour cela qui sera judicieux de prendre soin de noter les problématiques rencontrées et de donner un certain fil de développement pour venir à bout de la problématique posée.
Ce qui reviendra à proposer des axes/questions sur les manipulations de cette maquette de TP.

== Note valable pour toutes les semaines ==

'''[[Si un point vous semble imprécis, veuillez vous reporter aux détails fournis en annexe.]]'''

== 1éme semaine: (du 27/01/2014 au 01/02/2014) ==

Séance du 05/02/2014 :

Pour bien comprendre les différentes choses à réaliser, on a refait les manipulations vues en TP. On a, pour cela utiliser la maquette didactique TIMS pour générer différent type de modulation:

-la modulation en 4,8,16PSK (on obtient une constellation en forme de cercle).

-La modulation en 4,8,16QAM (on obtient une constellation avec un carré, ou deux: de différentes tailles).

On a très vite dégagé la nécessité de réaliser un montage générateur de tous les mots numériques possibles.
On a donc fait un programme sur arduino qui équivaut au générateur pseudo aléatoire.
Celui-ci est directement inspiré du montage que l'on a réalisé l'année dernière en conception de circuit électronique.

Séance du 06/02/2014 :

Lors de cette séance on a exploré toutes les possibilités concernant la communication entre la maquette/carte, car cela pour avoir une influence non négligeable sur le choix de la carte F.P.G.A. et du design de la maquette.

On a donc aussi fait des recherches concernant les possibilités de communications et les blocs I.P. (Intellectual Properties) permettant de programmer un F.P.G.A.

Et enfin, on a eu une discussion avec un responsable technique pour ce qui de la C.E.M. (Compatibilité Electro-Magnétique)

== 2éme semaine: (du 03/02/2014 au 08/02/2014) ==

Réflexion sur les possibilités possibles et offertes par le sujet pour ce qui est des parties de communications entre la maquette en interne et de son environnement.

[[Fichier:P34_2013_2014_schéma_principe_carte_semaine_2.PNG|300px|thumb|center|Maquette en interne/externe.]]

N'ayant jamais utilisé d'autre carte que la Nanoboard, on s'est attelé à faire des recherches sur la manière de procéder pour programmer une carte F.P.G.A., il se trouve que chaque carte de développement à ses propres manières pour être programmé.

On a pris le soin de noter toutes les questions concernant le F.P.G.A. pour un intervenant industriel qui assura un cours la semaine prochaine.

== 3éme semaine: (du 10/02/2014 au 15/02/2014) ==

Ayant les oscillateurs commandables en tension, on a pu commencer à faire une manipulation avec les composants Mini-Circuit.

Mais après un problème suite à une manipulation l'un des VCOs ne fonctionne plus.

Ce qui nous amène à penser qu'il sera judicieux de prévoir une alimentation au niveau de la carte.

Celle-ci devra être inférieure ou égale à la tension maximale d'alimentation du composant (ceux-ci étant très sensible).

Questions/Réponses:

Comment fait-on pour programmer une carte F.P.G.A. est-ce que la programmation se fait "in situe" ? (in situe : c'est à dire sur la carte elle-même)
Oui, c'est ce qui est utilisé, via un câble JTAG.

Est-ce possible faire une interface USB pour permettre à un ordinateur de communiquer avec la maquette/carte via un F.P.G.A. ? Oui.

Est-ce que la gestion de l'interface Ethernet est envisageable ? Oui.

Pour une communication en protocole UDP avec un ordinateur via une liaison Ethernet, est-ce qu'il y a d'autres façons que d'utiliser un "SoftCore" ?

Oui, il existe aussi bien en Software, qu'en Hardware.

== 4éme semaine: (du 17/02/2014 au 22/02/2014) ==

On a donc repris l'idée de la 2éme semaine.

Après avoir mis en place un cahier des charges au niveau des qualités, bande passante minimale.

Nous avons fait des recherches sur les composants à utiliser (i.e. CAN, CAN, ...)

Ce qui nous a permis après une édition rapide de schéma électrique (schematic) d'avoir une idée du nombre de pins dont nous aurons besoin sur une carte FPGA afin de réaliser le projet.

Après prospection, il se trouve que nous nous dirigerions vers la carte Digilent Spartan 3, dont l'école était déjà en possession.

Donc nous nous sommes attelés à faire des recherches et des essais sur cette carte et pour notamment trouver un moyen de la faire fonctionner.

== 5éme semaine: (du 03/03/2014 au 08/03/2014) ==

Tout d'abord, après plusieurs heures de recherches et d'essai infructueux, on a fini par trouver les drivers pour le câble USB diligent.

Et donc ainsi avoir un fonctionnement de la communication via le câble JTAG plus propice au fonctionnement de la carte.

On a pu enfin se conforter sur une partie des composants et des dimensionnements pour certains d'entre eux (valeur de résistance,capacité...)

Schématics: Édition de multiple bibliothèque pour Altium, intégrant à la fois schématics et leur empreinte PCB associée.

(On a pu constater qu'une interface 3v3 5v n'est pas forcement nécessaire pour assurer le bon fonctionnement entre deux cartes avec des tensions d'alimentation différentes.)

== 6éme semaine: (du 10/03/2014 au 15/03/2014) ==

On a pu enfin se conforter sur l'ensemble des composants et des choix de régulateur et utilisation d'autre diode Zener.

On trouvera le schéma intégral avec les bibliothèques nécessaires dans la semaine 5.

Cette semaine a été dédiée à l'envoi de la commande des composants au sein du magasin de l'école et du fournisseur.

Après envoi de la commande, il se trouve que le projet a changé d'objectif principal.

Il est maintenant prioritaire de réaliser un code VHDL capable d'évaluer la vitesse de transmission numérique du côté récepteur.

== 7éme semaine: (du 17/03/2014 au 22/03/2014) ==

Pour cette semaine, on s'est concentré sur la réalisation d'un générateur pseudo aléatoire en interne au FPGA.

On réalisera une échelle de résistance afin de réaliser une conversion numérique analogique afin de l'envoyer sur la chaine de transmission.

Ce code de "base" nous permettra de réaliser un flux de données fictif pour obtenir toutes les combinaisons récupérant le résultat du bus.

[[MédiaP34_2013_2014_gene_pseudo_19_03_2014_6_semaine_7.zip|Archive contenant le projet ISE Xilinx.]]

[[Fichier:P34_2013_2014_rtl_semaine_7.PNG|300px|thumb|center|extrait du schéma RTL, on peut y voir clairement les inférences de Xilinx.]]

Ce schéma a deux entrées et une sortie, une entrée d'initialisation, une horloge et une sortie pour la trame en pseudo aléatoire.

On fera l'essai sur la carte lors de la semaine suivante.

== 8éme semaine: (du 24/03/2014 au 26/03/2014) ==

Après le premier test, on pourrait penser que l'on récupère du bruit en sortie de la carte:

[[Fichier:P34_2013_2014_DSC_0024_1_probleme_d_overshoot_semaine_8.jpg|300px|thumb|center|Overshoot.]]

Pour pouvoir remédier à ce problème, on a fait une prédivision de l'horloge

[[Fichier:P34_2013_2014_DSC_0037_1_div_freq_semaine_8.jpg|300px|thumb|center|Overshoot après division.]]

[[Fichier:P34_2013_2014_DSC_0039_1_div_freq_zoom_semaine_8.jpg|300px|thumb|center|Overshoot après division (Zoom).]]

Archive contenant toutes les modifications:

[[Média:P34_2013_2014_gene_pseudo_26_03_2014_2_semaine_8.zip|VHDL Semaine 8.]]

On a trouvé un moyen de faire un CNA facilement, via une "échelle dite R-2R". [[http://www.uchobby.com/index.php/2008/01/08/arduino-audio-dac-options/|Pour le réseau R 2R.]]

Il faut encore modifier le VHDL pour pouvoir l'exploiter et ainsi générer une constellation.

== 9éme semaine: (du 28/03/2014 au 03/04/2014) ==

On a pris donc le soin de modifier le VHDL:

[[Média:P34_2013_2014_gene_pseudo_31_03_2014_1_semaine_9.zip|VHDL semaine 9]]

Ce VHDL à été mis à jour, avec deux entrées (initialisation et une horloge) et un bus de sortie (8 bits), avec les trames pseudoaléatoires.

On envoie ces signaux sur deux C.N.A.s (4 bits chacun) pour générer deux signaux I et Q, on peut voir une constellation se dessiner en mode X-Y.

[[Fichier:P34_2013_2014_DSC_0072_1_Montage_entier_4qam_semaine_9.jpg|300px|thumb|center|Montage avec constellations 4QAM.]]

D'autres constellations réalisées sont disponibles en annexe. On peut monter jusqu'à une constellation de 256 points (2^4*2^4).

On a réalisé le montage complet de toute la chaine de transmission. Il se trouve que la Boucle à Verrouillage de Phase (ou appellée PLL, Phase Loop Locker) ne se verrouille pas sur la porteuse du signal que l'on souhaite récupéré, de ce fait on ne peut pas récupérer les signaux I et Q.

== 10éme semaine: (du 07/04/2014 au 10/04/2014) ==

On a réalisé le montage que l'on évoquait en semaine 9:

[[Fichier:P34_2013_2014_DSC_0027_montage_realisee_semaine_10.jpg|center|thumb|300px|Montage pour améliorer la PLL.]]

Il se trouve qu’après un réglage précis de la tension d'offset permettant d'être un proche de la fréquence à capturer on obtient:

[[Fichier:P34_2013_2014_DSC_0025_PLL_non_verrouillage_semaine_10.jpg|center|thumb|300px|Signaux I/Q après ajout du montage.]]

== Conclusion: ==

Ce projet intéressant m'a permis de prendre conscience les différences fondamentales entre la théorie et la pratique. Cela m'a permis de prendre conscience que faut toujours avoir un esprit critique envers la théorie, car il faut savoir découvrir l'origine du problème en cas de dysfonctionnement, car le travail d'un ingénieur ne se limite pas à fournir des solutions.

Mon projet scolaire s'est donc achevé à ce point, cependant d'autres élèves pourront prendre le relais en réalisant la carte correspondant au schéma et ainsi réaliser rapidement l'interface entre la carte FPGA et la maquette. Et pourront se concentrer sur la mise en route intégrale de la chaine.

= Annexes =

== Annexe A: Détails techniques des semaines ==

=== 1éme semaine: (du 27/01/2014 au 01/02/2014) ===

Après on a réfléchi sur la potentielle conception/utilisation d'une carte FPGA.
Il sera judicieux de ne pas se précipiter sur le schéma et la conception/utilisation d'une carte FPGA, sans avoir, au préalable fait le VHDL et le testez avec un banc de test virtuel.
L'intérêt et de mettre en valeur la nécessité ou non de certains signaux pour le schéma de la carte.
On va mettre en oeuvre les connaissances acquises au S7 en VHDL (en TP de Circuit Numérique Programmble).

Pour ce qui est de l'Arduino, on a répondu aux interrogations suivantes (certaines de ces questions paraissent triviales, mais on préfère éviter les surprises):

Quelle est la vitesse maximale de la communication série de l'Arduino ?
-115200bauds

Est-ce que, un programme de type "Analog Write" est-il une vraie sortie analogique ?

-Non, c'est juste une PWM. Elle sera exploitable pour faire les signales I/Q mais très contraignantes, car il faudra filtré le signal, et ce sera beaucoup trop lent (du au fait que la modulation est faite au alentour de 850Mhz), le FPGA sera un passage obligé cela ouvrira les portes d'un plus grand débit.

==== Manipulation réalisée sur la maquette TIMS : ====

On a fait un des montages présentés dans l'ouvrage "Volume D1 Fundamental Digital Experiments" dans le but de visualiser l’objectif à atteindre.

On obtient la constellation suivante (16QAM):

[[Fichier:P34_2013_2014_constelation_tims_semaine_1.PNG|300px|thumb|center|Constellation visualisée en mode X-Y.]]

Ce qui correspond à deux signaux en visualisation temporelle de cette forme :

[[Fichier:P34_2013_2014_constelation_temporelle_tims_semaine_1.PNG|300px|thumb|center|Signaux I et Q. (Image très floutée, à remplacer)]]

On pourra facilement obtenir le même résultat en générant un bus de trame pseudo aléatoire et en l'injectant dans un C.N.A. (Conversion Numérique Analogique)

==== Code Arduino réalisé: ====

[[Fichier:P34_2013_2014_schema_electronique_generateur_pseudo_aleatoire.png|300px|thumb|center|Schéma électronique du générateur pseudo aléatoire.]]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_chrono_simule.PNG|300px|thumb|center|Résultat de la simulation du générateur pseudo aléatoire (on a eu la même chose en pratique).]]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_arduino.jpg|300px|thumb|center|Resultat avec le générateur pseudo aléatoire "émuler" avec l'Arduino.]]

Comparaison carte réelle/résultat Arduino:

C'était exactement les signaux attendus (même s'il y un décalage a par rapport à l'original).

On aura bien pour une QPSK (4PSK) tous les couples (ie 00,01,11 et 10).

À propos de l'arduino, on pourra envisager une amélioration pour générer une séquence plus longue:

-il faudra simplement utiliser un tableau d'entier.

-paramétrer sa taille avec un N par exemple.

-N correspondra à la taille de séquence de longueur 2^N.

Voir la section "Code Arduino réalisé" en annexe B dans la semaine correspondante.

==== Possibilités de communications: ====

Exploration des possibilités de communication entre le PC et la carte en amont:

=====-> Ethernet: =====

*+ Vitesse de transmission (~10M-100M-G)bauds

*- La gestion du flux de données doit être faite par un microcontrôleur (celui-ci pourra être implémenté un bloc I.P. à l'intérieur du FPGA)

-> - Haute consommation de CLB du FPGA.

=====-> SPI (communication série): =====

*- Vitesse de transmission

-> Arduino capable de communiquer jusqu'a 115200 bauds

-> D'après certaines discussions sur des forums, on pourrait « pousser » au-delà.

=====-> I2C : =====

Communication abandonnée, ce n'est pas une priorité.

==== À propos des blocs I.P.: ====

En consultant les ordinateurs et en s'appuyant des T.P.s de CNP, on constate que les blocs suivants existent:

- Xilinx Microblaze/Xilinx Power PC ("µP FPGA")

-> Est-ce possible d'utiliser ces blocs I.P. pour programmer un FPGA sur une carte autre que la Nanoboard ? Comment ?

- EMACx (Ethernet Media Acess Control)(:lien physique entre processeurs et "standart Physical Layer device IEEE802.3")

===== Conception de la carte: =====

L'idéal est de se documenter sur la Compatibilité électromagnétique.

=== 2éme semaine: (du 03/02/2014 au 08/02/2014) ===

(Rien pour l'annexe.)

=== 3éme semaine: (du 10/02/2014 au 15/02/2014) ===

Lors de cette semaine, après avoir eu le problème de manipulation, nous avons pu prendre connaissance d'un certain montage qui s’avéra utile pour la conception de la carte/maquette.

[[Fichier:P34_2013_2014_schéma_limiteur_de_courant_semaine_3.PNG|300px|thumb|center|Schéma limiteur de courant.]]

On remarquera que ce montage se retrouve dans la partie "typical application" de la documentation technique du 7805.

=== 4éme semaine: (du 17/02/2014 au 22/02/2014) ===

On souhaite pouvoir réaliser une communication unidirectionnelle ou même transmettre un signal audio ce qui nous contraint à une bande passante minimale de 48kHz, on prendra 200kHz (pour être bien au-delà de la condition du théorème de Shannon): le but serait donc de brancher par exemple une source audio quelconque puis de la transmettre à travers la maquette et de la recomposer en fin de chaine.

Après édition rapide du schéma, on en dégage qu'il nous faudra un minimum d'environ 50 entrées/sorties. Mais ceci ce nombre sera très probablement revu à la hausse lors de prochaine séance.

Voici la carte que l'on utilisera dans la suite du projet:

[[Fichier:P34_2013_2014_S3BOARD-top-400_semaine_4.gif|300px|thumb|center|Digilent Spartan 3.]]

=== 5éme semaine: (du 03/03/2014 au 08/03/2014) ===

Lien vers le Design complet avec les librairies incluses (on remarquera qu'il serait judicieux d’installer toutes les librairies avant d’essayer d'ouvrir le schéma)

A notez aussi que l'on trouvera des reliques de feuilles Excel permettant de trouver rapidement des ratios dans la série E12.

[[Média:P34_2013_2014_Design_pcb_plus_librairies_semaine_5_6.zip|Schéma + Bibliothèques.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.pdf|Schéma en PDF.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.png|Schéma au format A2.]]

=== 6éme semaine: (du 10/03/2014 au 15/03/2014) ===

(Rien pour l'annexe.)

=== 7éme semaine: (du 17/03/2014 au 22/03/2014) ===

(Rien pour l'annexe.)

=== 8éme semaine: (du 24/03/2014 au 26/03/2014) ===

(Rien pour l'annexe.)

=== 9éme semaine: (du 28/03/2014 au 03/04/2014) ===

[[Fichier:P34_2013_2014_DSC_0061_1_r_2r_semaine_9.jpg|center|thumb|300px|Le réseau R-2R.]]

[[Fichier:P34_2013_2014_DSC_0062_1_4QAM_semaine_9.jpg|center|thumb|300px|4QAM.]]

[[Fichier:P34_2013_2014_DSC_0066_1_16QAM_semaine_9.jpg|center|thumb|300px|16QAM.]]

[[Fichier:P34_2013_2014_DSC_0069_1_64QAM_semaine_9.jpg|center|thumb|300px|64QAM.]]

Pas de photos pour la constellation à 256 points, mais elle a été réalisée.

Pour ce qui est du montage, malgré que la P.L.L., on a un signal d'erreur après filtrage :

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Chaine 1: Vtune (commande du V.C.O.)/Chaine 2: "erreur" de commande]]

Ce qui met en valeur immédiatement deux problèmes majeurs:

La chaine fonctionne sur le papier, mais lors de sa mise en pratique, il faut penser à mettre une tension d'offset et aussi réaliser une amplification de l'erreur pour avoir des grandeurs de commande adaptée au Vtune du V.C.O..

On propose l'amélioration suivante (qui sera réalisé à la prochaine séance):

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Proposition de voie d'amélioration.]]

On remarquera que les valeurs des résistances et des capacités on était choisi pour permettre un fonctionnement correct des A.O. (Amplificateur Opérationnel), mais pas pour ce qui de l'asservissement de la boucle par manque de temps.

A la fin de cette, on a eu à démonter le montage à cause de contraintes concernant les Mini-circuits (car utilisé en travaux pratiques).

=== 10éme semaine: (du 07/04/2014 au 10/04/2014) ===

Spectres des signaux de la chaine de transmission:

[[Fichier:P34_2013_2014_DSC_0001_allure_spectre_reception_semaine_10.jpg|center|thumb|300px|Spectre en réception.]]

Porteuse utilisée pour la modulation I/Q à environ 60MHz.

Porteuse utilisée pour le transport en fréquence à environ 810MHz:

[[Fichier:P34_2013_2014_DSC_0035_constellation_recupere_PLL_NV_semaine_10.jpg|center|thumb|300px|"Constellation" récupérée avec la PLL défectueuse (on souhaite se verrouiller sur la raie à 868MHz).]]

Question en suspens: faudrait-il utiliser un filtre passe-bande incluant 868Mhz pour pouvoir se verrouiller sur cette fréquence ?

On remarquera le fait que l'oscillateur du côté de la chaine d'émission a d'importantes non-linéarités (on peut observer à l'analyseur de spectre 3 à 4 raies aux fréquences multiples).

Ce qui donne un diagramme de constellation plutôt mauvais si l'on fait le montage suivant:

[[Fichier:P34_2013_2014_montage_non_linearite_vco_constellation_semaine_10.PNG|center|thumb|300px|Montage réalisée.]]

[[Fichier:P34_2013_2014_sortie_montage_non_linearite_semaine_10.PNG|center|thumb|300px|La constellation 4QAM est attendue, on est loin du résultat attendu (aucune photo n'a était réalisé d'ou le dessin).]]

== Annexe B: Digilent Spartan 3 ==

=== Procédure pour faire fonctionner la carte Digilent Spartan 3: ===

Ne connectez pas de connecteur JTAG pendant les installations. Redémarrez après chaque installation.

Tout d'abord, il faut savoir que le l'ISE Webpack 14.6 fonctionne avec la carte (n'utilisez pas la 14.7, elle ne supporte pas la génération spartan 3 !):

Installez donc l'ISE WebPack 14.6 (ou antérieur à condition que celle-ci soit supérieur à la 7.1i (d'après leur documentation))

(voir lien utile sur Xilinx)

Une fois l'installation de l'ISE terminé, faites en sorte d'avoir celui que soit opérationnel (la licence est gratuite !).

Installez la "library" ADEPT 2.3 voir le lien utile.

Après vous n'avez plus qu'a utilisez ISE Xilinx normalement et vous serez capable de reconnaitre la carte via la liaison JTAG, et de le programmer.

=== Liens utiles: ===

Lien constructeur/vendeur (avec ressources utiles en bas de la page):

http://www.digilentinc.com/Products/Detail.cfm?Prod=S3BOARD

Lien "Library" pour le câble USB digilent:

http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,66,69&Prod=ADEPT

Lien Xilinx (Pour l'ISE 14.6):

http://www.xilinx.com/products/design-tools/ise-design-suite/index.htm

Lien Xilinx (Pour les versions antérieures veuillez faire attention au système d'exploitation, votre architecture matérielle et le FPGA cible):

(Les informations de compatibilité son sur la page suivante:) (mots clés: xilinx classic(s))

http://www.xilinx.com/tools/classics.htm

=== Procédure pour faire une programmation en volatile: ===

Générer le bitstream, et le charger.

=== Procédure pour faire une programmation en "non"-volatile: ===

Générer le bitstream et l'utiliser pour générer un .mcs qui vous permettra d'inscrire le programme dans la mémoire (E?)PROM.

On remarquera que la programmation en non volatile est utile pour faire un remise à zéro et recharger le contenu de l'(E?)PROM, mais semble être sensible au débranchement de l'adaptateur d'alimentation de la carte.

=== Exemple de programmation: ===

Voir le lien digilent pour ceci dans cette annexe.

= Fichiers Rendus =

Rapport projet numéro 34 VAESSEN :[[Fichier:Rapport_projet_p34_s8_6.pdf]]

Source VHDL Final :[[Fichier:P34_2013_2014_gene_pseudo_31_03_2014_1_semaine_9.zip]]

Code Arduino :[[Fichier:P34_2013_204_Generateur_pseudo.zip]]

Design sous Altium :[[Fichier:P34_2013_2014_Design_pcb_plus_librairies_semaine_5_6.zip]]

Fichier:Rapport projet p34 s8 6.pdf

2014-04-15T08:17:54Z

Jvaessen : a téléversé une nouvelle version de « Fichier:Rapport projet p34 s8 6.pdf »

Modem pour le numérique

2014-04-14T21:32:06Z

Jvaessen : /* Exemple de programmation: */

= Modulateur et démodulateur pour communications numériques =

== Cahier des charges ==

=== Présentation générale du projet ===

Dans le cadre des TPs d'électronique et de transmission RF, nous avons découvert qu'il existe plusieurs modes de modulation, pour transmettre un signal modulant.

Celles vues en TP au S7 sont la modulation en amplitude, en fréquence, en phase, en BPSK et en QPSK.

Or les modulations en phase, en fréquence et en amplitude étant celles les plus connues, la modulation en QAM (Modulation d'Amplitude en Quadrature) est quant à elle moins connue, mais tout aussi utilisées:

-pour la TNT en 64 QAM (en France).

[[Fichier:P34_2013_2014_64qam.jpg|300px|thumb|center|Exemple de constellation 64QAM.]]

-pour le WiFi en 64-QAM ou 256-QAM (à vérifier).

Or ces deux dernières étant peu représentées au niveau des travaux pratiques, ce projet permettra de fournir un peu plus de pratique sur les modulations de type QAM (en diagramme I/Q) dans le domaine des radiofréquences (~800MHz).

(Le nombre devant le QAM indique le nombre de points dans le diagramme I/Q qu'on appelle aussi constellation)

On se réserve le droit de faire '''évoluer''' le cahier des charges a posteriori, si certaines contraintes étaient amenées à évoluer ou se préciser.

=== Objectif et intérêt du projet ===

Pour cela, on nous a fourni des modules commerciaux Mini-circuit pouvant travailler dans les radios-fréquences.

Ceux-ci permettront de mettre en place une grande partie de la chaine de transmission (voir schéma de la chaine de transmission).

[[Fichier:P34_2013_2014_Chaine_modulation.PNG|300px|thumb|center|Modulation.]]

[[Fichier:P34_2013_2014_Chaine_demodulation.PNG|300px|thumb|center|Démodulation.]]

On a tout d'abord à mettre en place une carte FPGA et/ou un dispositif permettant d'envoyer un flux de données numériques continuellement pour pouvoir visualiser le diagramme I/Q (mise en valeur du diagramme I/Q et voir même un diagramme un peu plus complexe que le BPSK ou le QPSK).

Le canal de transmission qui sera un simple fil électrique, mais pourra devenir une antenne réceptrice et émettrice si le temps imparti le permet (mise en valeur du et mesure du Bit Error Rate qui sera bien sûr différent suivant le canal de transmission).

Du côté réception ,après démodulation du signal, une remise en forme et une interprétation des données seront réalisées, celle-ci dépendra bien entendu de la provenance du flux de données (constater le succès ou l'échec d'un envoi de données).

Enfin si le temps le permets on pourra mettre en une place un système de codage de l'information avec par exemple un codage redondant permettant de corrigé l'erreur (À définir, on pourra faire constater l'efficacité d'une méthode de codage au choix).

=== Étapes/Déroulement du projet ===

De même que pour le cahier des charges, il se peut que les étapes diffèrent plus ou moins, en fonction des disponibilités, matérielles et contraintes.

==== => Caractérisation des blocs Mini-circuits et épluchage des documentations techniques====
Avant de les utiliser dans la chaine de transmission, nous avons à faire une caractérisation des blocs fournis:

-la caractérisation du VCO.

-l'étude des possibilités offerte par le modulateur (cela déterminera le nombre de points possible dans la constellation, ie savoir si l'on peut aller au-delà de la QPSK).

-la caractérisation des mélangeurs (Mixer), leurs facteurs réels de multiplication.

==== => Utilisation et exploitation des caractérisations ====
On pourra ensuite trouver les paramètres pour régler correctement dans notre chaine de transmission certains de nos sous-systèmes comme la boucle à verrouillage de phase.

==== => Génération d'un flux des données numériques ====
Comme dit précédemment, l'idéal et d'avoir un flux de données numériques transmis en permanence.
Pour cela plusieurs solutions s'offre à nous, on pourra utiliser un montage générateur pseudo aléatoire (un circuit que l'on a fait l'année dernière en Conception de Circuit Électronique).
On pourra "émuler" ce montage avec un Arduino, ou bien même le faire au moyen de la Nanoboard.
On pourra aussi transmettre des chaines de caractère en continu.

==== => Test de la chaine ====
Une fois les étapes précédentes réalisées, on pourra passer au test de la chaine de transmission. Il faudra vérifier le bon fonctionnement en aval, dedans (boucle à verrouillage de phase), et en amont de la chaine de transmission.

==== => Première mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.
Il est possible que la conception d'un dispositif soit nécessaire que ce soit pour les deux mesures du B.E.R..

==== => Antennes ====
Si toutes les étapes précédentes sont satisfaites, on pourra alors faire un canal de transmission plus intéressant, à savoir l'air.
Nous passerons alors à la conception des antennes, émettrice et réceptrice.

==== => Deuxième mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.

==== => Codage de l'information et correction d'erreur ====
En toute fin de ce projet, on pourra même mettre deux dispositifs en aval et en amont de la chaine de transmission.
On réalisera alors un codeur et un décodeur permettant de faire de la détection/correction d'erreur.

==== => Mise en place d'outil de débogage (tout au long)====
La mise en place de simples outils de débogage et primordiale, ceux-ci permettront de vérifier le bon fonctionnement de la chaine.

==== => Proposition d'un sujet de TP (tout au long) ====
Il se trouve que lors du déroulement du projet, on pourra être amené à se poser des questions au niveau des réglages de la chaine de transmission.
Or il est fort probable que les élèves qui travailleront sur ce TP pourront alors se poser les mêmes questions.
C'est pour cela qui sera judicieux de prendre soin de noter les problématiques rencontrées et de donner un certain fil de développement pour venir à bout de la problématique posée.
Ce qui reviendra à proposer des axes/questions sur les manipulations de cette maquette de TP.

== Note valable pour toutes les semaines ==

'''[[Si un point vous semble imprécis, veuillez vous reporter aux détails fournis en annexe.]]'''

== 1éme semaine: (du 27/01/2014 au 01/02/2014) ==

Séance du 05/02/2014 :

Pour bien comprendre les différentes choses à réaliser, on a refait les manipulations vues en TP. On a, pour cela utiliser la maquette didactique TIMS pour générer différent type de modulation:

-la modulation en 4,8,16PSK (on obtient une constellation en forme de cercle).

-La modulation en 4,8,16QAM (on obtient une constellation avec un carré, ou deux: de différentes tailles).

On a très vite dégagé la nécessité de réaliser un montage générateur de tous les mots numériques possibles.
On a donc fait un programme sur arduino qui équivaut au générateur pseudo aléatoire.
Celui-ci est directement inspiré du montage que l'on a réalisé l'année dernière en conception de circuit électronique.

Séance du 06/02/2014 :

Lors de cette séance on a exploré toutes les possibilités concernant la communication entre la maquette/carte, car cela pour avoir une influence non négligeable sur le choix de la carte F.P.G.A. et du design de la maquette.

On a donc aussi fait des recherches concernant les possibilités de communications et les blocs I.P. (Intellectual Properties) permettant de programmer un F.P.G.A.

Et enfin, on a eu une discussion avec un responsable technique pour ce qui de la C.E.M. (Compatibilité Electro-Magnétique)

== 2éme semaine: (du 03/02/2014 au 08/02/2014) ==

Réflexion sur les possibilités possibles et offertes par le sujet pour ce qui est des parties de communications entre la maquette en interne et de son environnement.

[[Fichier:P34_2013_2014_schéma_principe_carte_semaine_2.PNG|300px|thumb|center|Maquette en interne/externe.]]

N'ayant jamais utilisé d'autre carte que la Nanoboard, on s'est attelé à faire des recherches sur la manière de procéder pour programmer une carte F.P.G.A., il se trouve que chaque carte de développement à ses propres manières pour être programmé.

On a pris le soin de noter toutes les questions concernant le F.P.G.A. pour un intervenant industriel qui assura un cours la semaine prochaine.

== 3éme semaine: (du 10/02/2014 au 15/02/2014) ==

Ayant les oscillateurs commandables en tension, on a pu commencer à faire une manipulation avec les composants Mini-Circuit.

Mais après un problème suite à une manipulation l'un des VCOs ne fonctionne plus.

Ce qui nous amène à penser qu'il sera judicieux de prévoir une alimentation au niveau de la carte.

Celle-ci devra être inférieure ou égale à la tension maximale d'alimentation du composant (ceux-ci étant très sensible).

Questions/Réponses:

Comment fait-on pour programmer une carte F.P.G.A. est-ce que la programmation se fait "in situe" ? (in situe : c'est à dire sur la carte elle-même)
Oui, c'est ce qui est utilisé, via un câble JTAG.

Est-ce possible faire une interface USB pour permettre à un ordinateur de communiquer avec la maquette/carte via un F.P.G.A. ? Oui.

Est-ce que la gestion de l'interface Ethernet est envisageable ? Oui.

Pour une communication en protocole UDP avec un ordinateur via une liaison Ethernet, est-ce qu'il y a d'autres façons que d'utiliser un "SoftCore" ?

Oui, il existe aussi bien en Software, qu'en Hardware.

== 4éme semaine: (du 17/02/2014 au 22/02/2014) ==

On a donc repris l'idée de la 2éme semaine.

Après avoir mis en place un cahier des charges au niveau des qualités, bande passante minimale.

Nous avons fait des recherches sur les composants à utiliser (i.e. CAN, CAN, ...)

Ce qui nous a permis après une édition rapide de schéma électrique (schematic) d'avoir une idée du nombre de pins dont nous aurons besoin sur une carte FPGA afin de réaliser le projet.

Après prospection, il se trouve que nous nous dirigerions vers la carte Digilent Spartan 3, dont l'école était déjà en possession.

Donc nous nous sommes attelés à faire des recherches et des essais sur cette carte et pour notamment trouver un moyen de la faire fonctionner.

== 5éme semaine: (du 03/03/2014 au 08/03/2014) ==

Tout d'abord, après plusieurs heures de recherches et d'essai infructueux, on a fini par trouver les drivers pour le câble USB diligent.

Et donc ainsi avoir un fonctionnement de la communication via le câble JTAG plus propice au fonctionnement de la carte.

On a pu enfin se conforter sur une partie des composants et des dimensionnements pour certains d'entre eux (valeur de résistance,capacité...)

Schématics: Édition de multiple bibliothèque pour Altium, intégrant à la fois schématics et leur empreinte PCB associée.

(On a pu constater qu'une interface 3v3 5v n'est pas forcement nécessaire pour assurer le bon fonctionnement entre deux cartes avec des tensions d'alimentation différentes.)

== 6éme semaine: (du 10/03/2014 au 15/03/2014) ==

On a pu enfin se conforter sur l'ensemble des composants et des choix de régulateur et utilisation d'autre diode Zener.

On trouvera le schéma intégral avec les bibliothèques nécessaires dans la semaine 5.

Cette semaine a été dédiée à l'envoi de la commande des composants au sein du magasin de l'école et du fournisseur.

Après envoi de la commande, il se trouve que le projet a changé d'objectif principal.

Il est maintenant prioritaire de réaliser un code VHDL capable d'évaluer la vitesse de transmission numérique du côté récepteur.

== 7éme semaine: (du 17/03/2014 au 22/03/2014) ==

Pour cette semaine, on s'est concentré sur la réalisation d'un générateur pseudo aléatoire en interne au FPGA.

On réalisera une échelle de résistance afin de réaliser une conversion numérique analogique afin de l'envoyer sur la chaine de transmission.

Ce code de "base" nous permettra de réaliser un flux de données fictif pour obtenir toutes les combinaisons récupérant le résultat du bus.

[[MédiaP34_2013_2014_gene_pseudo_19_03_2014_6_semaine_7.zip|Archive contenant le projet ISE Xilinx.]]

[[Fichier:P34_2013_2014_rtl_semaine_7.PNG|300px|thumb|center|extrait du schéma RTL, on peut y voir clairement les inférences de Xilinx.]]

Ce schéma a deux entrées et une sortie, une entrée d'initialisation, une horloge et une sortie pour la trame en pseudo aléatoire.

On fera l'essai sur la carte lors de la semaine suivante.

== 8éme semaine: (du 24/03/2014 au 26/03/2014) ==

Après le premier test, on pourrait penser que l'on récupère du bruit en sortie de la carte:

[[Fichier:P34_2013_2014_DSC_0024_1_probleme_d_overshoot_semaine_8.jpg|300px|thumb|center|Overshoot.]]

Pour pouvoir remédier à ce problème, on a fait une prédivision de l'horloge

[[Fichier:P34_2013_2014_DSC_0037_1_div_freq_semaine_8.jpg|300px|thumb|center|Overshoot après division.]]

[[Fichier:P34_2013_2014_DSC_0039_1_div_freq_zoom_semaine_8.jpg|300px|thumb|center|Overshoot après division (Zoom).]]

Archive contenant toutes les modifications:

[[Média:P34_2013_2014_gene_pseudo_26_03_2014_2_semaine_8.zip|VHDL Semaine 8.]]

On a trouvé un moyen de faire un CNA facilement, via une "échelle dite R-2R". [[http://www.uchobby.com/index.php/2008/01/08/arduino-audio-dac-options/|Pour le réseau R 2R.]]

Il faut encore modifier le VHDL pour pouvoir l'exploiter et ainsi générer une constellation.

== 9éme semaine: (du 28/03/2014 au 03/04/2014) ==

On a pris donc le soin de modifier le VHDL:

[[Média:P34_2013_2014_gene_pseudo_31_03_2014_1_semaine_9.zip|VHDL semaine 9]]

Ce VHDL à été mis à jour, avec deux entrées (initialisation et une horloge) et un bus de sortie (8 bits), avec les trames pseudoaléatoires.

On envoie ces signaux sur deux C.N.A.s (4 bits chacun) pour générer deux signaux I et Q, on peut voir une constellation se dessiner en mode X-Y.

[[Fichier:P34_2013_2014_DSC_0072_1_Montage_entier_4qam_semaine_9.jpg|300px|thumb|center|Montage avec constellations 4QAM.]]

D'autres constellations réalisées sont disponibles en annexe. On peut monter jusqu'à une constellation de 256 points (2^4*2^4).

On a réalisé le montage complet de toute la chaine de transmission. Il se trouve que la Boucle à Verrouillage de Phase (ou appellée PLL, Phase Loop Locker) ne se verrouille pas sur la porteuse du signal que l'on souhaite récupéré, de ce fait on ne peut pas récupérer les signaux I et Q.

== 10éme semaine: (du 07/04/2014 au 10/04/2014) ==

On a réalisé le montage que l'on évoquait en semaine 9:

[[Fichier:P34_2013_2014_DSC_0027_montage_realisee_semaine_10.jpg|center|thumb|300px|Montage pour améliorer la PLL.]]

Il se trouve qu’après un réglage précis de la tension d'offset permettant d'être un proche de la fréquence à capturer on obtient:

[[Fichier:P34_2013_2014_DSC_0025_PLL_non_verrouillage_semaine_10.jpg|center|thumb|300px|Signaux I/Q après ajout du montage.]]

= Annexes =

== Annexe A: Détails techniques des semaines ==

=== 1éme semaine: (du 27/01/2014 au 01/02/2014) ===

Après on a réfléchi sur la potentielle conception/utilisation d'une carte FPGA.
Il sera judicieux de ne pas se précipiter sur le schéma et la conception/utilisation d'une carte FPGA, sans avoir, au préalable fait le VHDL et le testez avec un banc de test virtuel.
L'intérêt et de mettre en valeur la nécessité ou non de certains signaux pour le schéma de la carte.
On va mettre en oeuvre les connaissances acquises au S7 en VHDL (en TP de Circuit Numérique Programmble).

Pour ce qui est de l'Arduino, on a répondu aux interrogations suivantes (certaines de ces questions paraissent triviales, mais on préfère éviter les surprises):

Quelle est la vitesse maximale de la communication série de l'Arduino ?
-115200bauds

Est-ce que, un programme de type "Analog Write" est-il une vraie sortie analogique ?

-Non, c'est juste une PWM. Elle sera exploitable pour faire les signales I/Q mais très contraignantes, car il faudra filtré le signal, et ce sera beaucoup trop lent (du au fait que la modulation est faite au alentour de 850Mhz), le FPGA sera un passage obligé cela ouvrira les portes d'un plus grand débit.

==== Manipulation réalisée sur la maquette TIMS : ====

On a fait un des montages présentés dans l'ouvrage "Volume D1 Fundamental Digital Experiments" dans le but de visualiser l’objectif à atteindre.

On obtient la constellation suivante (16QAM):

[[Fichier:P34_2013_2014_constelation_tims_semaine_1.PNG|300px|thumb|center|Constellation visualisée en mode X-Y.]]

Ce qui correspond à deux signaux en visualisation temporelle de cette forme :

[[Fichier:P34_2013_2014_constelation_temporelle_tims_semaine_1.PNG|300px|thumb|center|Signaux I et Q. (Image très floutée, à remplacer)]]

On pourra facilement obtenir le même résultat en générant un bus de trame pseudo aléatoire et en l'injectant dans un C.N.A. (Conversion Numérique Analogique)

==== Code Arduino réalisé: ====

[[Fichier:P34_2013_2014_schema_electronique_generateur_pseudo_aleatoire.png|300px|thumb|center|Schéma électronique du générateur pseudo aléatoire.]]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_chrono_simule.PNG|300px|thumb|center|Résultat de la simulation du générateur pseudo aléatoire (on a eu la même chose en pratique).]]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_arduino.jpg|300px|thumb|center|Resultat avec le générateur pseudo aléatoire "émuler" avec l'Arduino.]]

Comparaison carte réelle/résultat Arduino:

C'était exactement les signaux attendus (même s'il y un décalage a par rapport à l'original).

On aura bien pour une QPSK (4PSK) tous les couples (ie 00,01,11 et 10).

À propos de l'arduino, on pourra envisager une amélioration pour générer une séquence plus longue:

-il faudra simplement utiliser un tableau d'entier.

-paramétrer sa taille avec un N par exemple.

-N correspondra à la taille de séquence de longueur 2^N.

Voir la section "Code Arduino réalisé" en annexe B dans la semaine correspondante.

==== Possibilités de communications: ====

Exploration des possibilités de communication entre le PC et la carte en amont:

=====-> Ethernet: =====

*+ Vitesse de transmission (~10M-100M-G)bauds

*- La gestion du flux de données doit être faite par un microcontrôleur (celui-ci pourra être implémenté un bloc I.P. à l'intérieur du FPGA)

-> - Haute consommation de CLB du FPGA.

=====-> SPI (communication série): =====

*- Vitesse de transmission

-> Arduino capable de communiquer jusqu'a 115200 bauds

-> D'après certaines discussions sur des forums, on pourrait « pousser » au-delà.

=====-> I2C : =====

Communication abandonnée, ce n'est pas une priorité.

==== À propos des blocs I.P.: ====

En consultant les ordinateurs et en s'appuyant des T.P.s de CNP, on constate que les blocs suivants existent:

- Xilinx Microblaze/Xilinx Power PC ("µP FPGA")

-> Est-ce possible d'utiliser ces blocs I.P. pour programmer un FPGA sur une carte autre que la Nanoboard ? Comment ?

- EMACx (Ethernet Media Acess Control)(:lien physique entre processeurs et "standart Physical Layer device IEEE802.3")

===== Conception de la carte: =====

L'idéal est de se documenter sur la Compatibilité électromagnétique.

=== 2éme semaine: (du 03/02/2014 au 08/02/2014) ===

(Rien pour l'annexe.)

=== 3éme semaine: (du 10/02/2014 au 15/02/2014) ===

Lors de cette semaine, après avoir eu le problème de manipulation, nous avons pu prendre connaissance d'un certain montage qui s’avéra utile pour la conception de la carte/maquette.

[[Fichier:P34_2013_2014_schéma_limiteur_de_courant_semaine_3.PNG|300px|thumb|center|Schéma limiteur de courant.]]

On remarquera que ce montage se retrouve dans la partie "typical application" de la documentation technique du 7805.

=== 4éme semaine: (du 17/02/2014 au 22/02/2014) ===

On souhaite pouvoir réaliser une communication unidirectionnelle ou même transmettre un signal audio ce qui nous contraint à une bande passante minimale de 48kHz, on prendra 200kHz (pour être bien au-delà de la condition du théorème de Shannon): le but serait donc de brancher par exemple une source audio quelconque puis de la transmettre à travers la maquette et de la recomposer en fin de chaine.

Après édition rapide du schéma, on en dégage qu'il nous faudra un minimum d'environ 50 entrées/sorties. Mais ceci ce nombre sera très probablement revu à la hausse lors de prochaine séance.

Voici la carte que l'on utilisera dans la suite du projet:

[[Fichier:P34_2013_2014_S3BOARD-top-400_semaine_4.gif|300px|thumb|center|Digilent Spartan 3.]]

=== 5éme semaine: (du 03/03/2014 au 08/03/2014) ===

Lien vers le Design complet avec les librairies incluses (on remarquera qu'il serait judicieux d’installer toutes les librairies avant d’essayer d'ouvrir le schéma)

A notez aussi que l'on trouvera des reliques de feuilles Excel permettant de trouver rapidement des ratios dans la série E12.

[[Média:P34_2013_2014_Design_pcb_plus_librairies_semaine_5_6.zip|Schéma + Bibliothèques.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.pdf|Schéma en PDF.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.png|Schéma au format A2.]]

=== 6éme semaine: (du 10/03/2014 au 15/03/2014) ===

(Rien pour l'annexe.)

=== 7éme semaine: (du 17/03/2014 au 22/03/2014) ===

(Rien pour l'annexe.)

=== 8éme semaine: (du 24/03/2014 au 26/03/2014) ===

(Rien pour l'annexe.)

=== 9éme semaine: (du 28/03/2014 au 03/04/2014) ===

[[Fichier:P34_2013_2014_DSC_0061_1_r_2r_semaine_9.jpg|center|thumb|300px|Le réseau R-2R.]]

[[Fichier:P34_2013_2014_DSC_0062_1_4QAM_semaine_9.jpg|center|thumb|300px|4QAM.]]

[[Fichier:P34_2013_2014_DSC_0066_1_16QAM_semaine_9.jpg|center|thumb|300px|16QAM.]]

[[Fichier:P34_2013_2014_DSC_0069_1_64QAM_semaine_9.jpg|center|thumb|300px|64QAM.]]

Pas de photos pour la constellation à 256 points, mais elle a été réalisée.

Pour ce qui est du montage, malgré que la P.L.L., on a un signal d'erreur après filtrage :

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Chaine 1: Vtune (commande du V.C.O.)/Chaine 2: "erreur" de commande]]

Ce qui met en valeur immédiatement deux problèmes majeurs:

La chaine fonctionne sur le papier, mais lors de sa mise en pratique, il faut penser à mettre une tension d'offset et aussi réaliser une amplification de l'erreur pour avoir des grandeurs de commande adaptée au Vtune du V.C.O..

On propose l'amélioration suivante (qui sera réalisé à la prochaine séance):

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Proposition de voie d'amélioration.]]

On remarquera que les valeurs des résistances et des capacités on était choisi pour permettre un fonctionnement correct des A.O. (Amplificateur Opérationnel), mais pas pour ce qui de l'asservissement de la boucle par manque de temps.

A la fin de cette, on a eu à démonter le montage à cause de contraintes concernant les Mini-circuits (car utilisé en travaux pratiques).

=== 10éme semaine: (du 07/04/2014 au 10/04/2014) ===

Spectres des signaux de la chaine de transmission:

[[Fichier:P34_2013_2014_DSC_0001_allure_spectre_reception_semaine_10.jpg|center|thumb|300px|Spectre en réception.]]

Porteuse utilisée pour la modulation I/Q à environ 60MHz.

Porteuse utilisée pour le transport en fréquence à environ 810MHz:

[[Fichier:P34_2013_2014_DSC_0035_constellation_recupere_PLL_NV_semaine_10.jpg|center|thumb|300px|"Constellation" récupérée avec la PLL défectueuse (on souhaite se verrouiller sur la raie à 868MHz).]]

Question en suspens: faudrait-il utiliser un filtre passe-bande incluant 868Mhz pour pouvoir se verrouiller sur cette fréquence ?

On remarquera le fait que l'oscillateur du côté de la chaine d'émission a d'importantes non-linéarités (on peut observer à l'analyseur de spectre 3 à 4 raies aux fréquences multiples).

Ce qui donne un diagramme de constellation plutôt mauvais si l'on fait le montage suivant:

[[Fichier:P34_2013_2014_montage_non_linearite_vco_constellation_semaine_10.PNG|center|thumb|300px|Montage réalisée.]]

[[Fichier:P34_2013_2014_sortie_montage_non_linearite_semaine_10.PNG|center|thumb|300px|La constellation 4QAM est attendue, on est loin du résultat attendu (aucune photo n'a était réalisé d'ou le dessin).]]

== Annexe B: Digilent Spartan 3 ==

=== Procédure pour faire fonctionner la carte Digilent Spartan 3: ===

Ne connectez pas de connecteur JTAG pendant les installations. Redémarrez après chaque installation.

Tout d'abord, il faut savoir que le l'ISE Webpack 14.6 fonctionne avec la carte (n'utilisez pas la 14.7, elle ne supporte pas la génération spartan 3 !):

Installez donc l'ISE WebPack 14.6 (ou antérieur à condition que celle-ci soit supérieur à la 7.1i (d'après leur documentation))

(voir lien utile sur Xilinx)

Une fois l'installation de l'ISE terminé, faites en sorte d'avoir celui que soit opérationnel (la licence est gratuite !).

Installez la "library" ADEPT 2.3 voir le lien utile.

Après vous n'avez plus qu'a utilisez ISE Xilinx normalement et vous serez capable de reconnaitre la carte via la liaison JTAG, et de le programmer.

=== Liens utiles: ===

Lien constructeur/vendeur (avec ressources utiles en bas de la page):

http://www.digilentinc.com/Products/Detail.cfm?Prod=S3BOARD

Lien "Library" pour le câble USB digilent:

http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,66,69&Prod=ADEPT

Lien Xilinx (Pour l'ISE 14.6):

http://www.xilinx.com/products/design-tools/ise-design-suite/index.htm

Lien Xilinx (Pour les versions antérieures veuillez faire attention au système d'exploitation, votre architecture matérielle et le FPGA cible):

(Les informations de compatibilité son sur la page suivante:) (mots clés: xilinx classic(s))

http://www.xilinx.com/tools/classics.htm

=== Procédure pour faire une programmation en volatile: ===

Générer le bitstream, et le charger.

=== Procédure pour faire une programmation en "non"-volatile: ===

Générer le bitstream et l'utiliser pour générer un .mcs qui vous permettra d'inscrire le programme dans la mémoire (E?)PROM.

On remarquera que la programmation en non volatile est utile pour faire un remise à zéro et recharger le contenu de l'(E?)PROM, mais semble être sensible au débranchement de l'adaptateur d'alimentation de la carte.

=== Exemple de programmation: ===

Voir le lien digilent pour ceci dans cette annexe.

= Fichiers Rendus =

Rapport projet numéro 34 VAESSEN :[[Fichier:Rapport_projet_p34_s8_6.pdf]]

Source VHDL Final :[[Fichier:P34_2013_2014_gene_pseudo_31_03_2014_1_semaine_9.zip]]

Code Arduino :[[Fichier:P34_2013_204_Generateur_pseudo.zip]]

Design sous Altium :[[Fichier:P34_2013_2014_Design_pcb_plus_librairies_semaine_5_6.zip]]

Fichier:P34 2013 204 Generateur pseudo.zip

2014-04-14T21:28:40Z

Jvaessen : a téléversé une nouvelle version de « Fichier:P34 2013 204 Generateur pseudo.zip »

Fichier:P34 2013 204 Generateur pseudo.zip

2014-04-14T21:28:17Z

Jvaessen :

Modem pour le numérique

2014-04-14T21:27:01Z

Jvaessen : /* Code Arduino réalisé: */

= Modulateur et démodulateur pour communications numériques =

== Cahier des charges ==

=== Présentation générale du projet ===

Dans le cadre des TPs d'électronique et de transmission RF, nous avons découvert qu'il existe plusieurs modes de modulation, pour transmettre un signal modulant.

Celles vues en TP au S7 sont la modulation en amplitude, en fréquence, en phase, en BPSK et en QPSK.

Or les modulations en phase, en fréquence et en amplitude étant celles les plus connues, la modulation en QAM (Modulation d'Amplitude en Quadrature) est quant à elle moins connue, mais tout aussi utilisées:

-pour la TNT en 64 QAM (en France).

[[Fichier:P34_2013_2014_64qam.jpg|300px|thumb|center|Exemple de constellation 64QAM.]]

-pour le WiFi en 64-QAM ou 256-QAM (à vérifier).

Or ces deux dernières étant peu représentées au niveau des travaux pratiques, ce projet permettra de fournir un peu plus de pratique sur les modulations de type QAM (en diagramme I/Q) dans le domaine des radiofréquences (~800MHz).

(Le nombre devant le QAM indique le nombre de points dans le diagramme I/Q qu'on appelle aussi constellation)

On se réserve le droit de faire '''évoluer''' le cahier des charges a posteriori, si certaines contraintes étaient amenées à évoluer ou se préciser.

=== Objectif et intérêt du projet ===

Pour cela, on nous a fourni des modules commerciaux Mini-circuit pouvant travailler dans les radios-fréquences.

Ceux-ci permettront de mettre en place une grande partie de la chaine de transmission (voir schéma de la chaine de transmission).

[[Fichier:P34_2013_2014_Chaine_modulation.PNG|300px|thumb|center|Modulation.]]

[[Fichier:P34_2013_2014_Chaine_demodulation.PNG|300px|thumb|center|Démodulation.]]

On a tout d'abord à mettre en place une carte FPGA et/ou un dispositif permettant d'envoyer un flux de données numériques continuellement pour pouvoir visualiser le diagramme I/Q (mise en valeur du diagramme I/Q et voir même un diagramme un peu plus complexe que le BPSK ou le QPSK).

Le canal de transmission qui sera un simple fil électrique, mais pourra devenir une antenne réceptrice et émettrice si le temps imparti le permet (mise en valeur du et mesure du Bit Error Rate qui sera bien sûr différent suivant le canal de transmission).

Du côté réception ,après démodulation du signal, une remise en forme et une interprétation des données seront réalisées, celle-ci dépendra bien entendu de la provenance du flux de données (constater le succès ou l'échec d'un envoi de données).

Enfin si le temps le permets on pourra mettre en une place un système de codage de l'information avec par exemple un codage redondant permettant de corrigé l'erreur (À définir, on pourra faire constater l'efficacité d'une méthode de codage au choix).

=== Étapes/Déroulement du projet ===

De même que pour le cahier des charges, il se peut que les étapes diffèrent plus ou moins, en fonction des disponibilités, matérielles et contraintes.

==== => Caractérisation des blocs Mini-circuits et épluchage des documentations techniques====
Avant de les utiliser dans la chaine de transmission, nous avons à faire une caractérisation des blocs fournis:

-la caractérisation du VCO.

-l'étude des possibilités offerte par le modulateur (cela déterminera le nombre de points possible dans la constellation, ie savoir si l'on peut aller au-delà de la QPSK).

-la caractérisation des mélangeurs (Mixer), leurs facteurs réels de multiplication.

==== => Utilisation et exploitation des caractérisations ====
On pourra ensuite trouver les paramètres pour régler correctement dans notre chaine de transmission certains de nos sous-systèmes comme la boucle à verrouillage de phase.

==== => Génération d'un flux des données numériques ====
Comme dit précédemment, l'idéal et d'avoir un flux de données numériques transmis en permanence.
Pour cela plusieurs solutions s'offre à nous, on pourra utiliser un montage générateur pseudo aléatoire (un circuit que l'on a fait l'année dernière en Conception de Circuit Électronique).
On pourra "émuler" ce montage avec un Arduino, ou bien même le faire au moyen de la Nanoboard.
On pourra aussi transmettre des chaines de caractère en continu.

==== => Test de la chaine ====
Une fois les étapes précédentes réalisées, on pourra passer au test de la chaine de transmission. Il faudra vérifier le bon fonctionnement en aval, dedans (boucle à verrouillage de phase), et en amont de la chaine de transmission.

==== => Première mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.
Il est possible que la conception d'un dispositif soit nécessaire que ce soit pour les deux mesures du B.E.R..

==== => Antennes ====
Si toutes les étapes précédentes sont satisfaites, on pourra alors faire un canal de transmission plus intéressant, à savoir l'air.
Nous passerons alors à la conception des antennes, émettrice et réceptrice.

==== => Deuxième mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.

==== => Codage de l'information et correction d'erreur ====
En toute fin de ce projet, on pourra même mettre deux dispositifs en aval et en amont de la chaine de transmission.
On réalisera alors un codeur et un décodeur permettant de faire de la détection/correction d'erreur.

==== => Mise en place d'outil de débogage (tout au long)====
La mise en place de simples outils de débogage et primordiale, ceux-ci permettront de vérifier le bon fonctionnement de la chaine.

==== => Proposition d'un sujet de TP (tout au long) ====
Il se trouve que lors du déroulement du projet, on pourra être amené à se poser des questions au niveau des réglages de la chaine de transmission.
Or il est fort probable que les élèves qui travailleront sur ce TP pourront alors se poser les mêmes questions.
C'est pour cela qui sera judicieux de prendre soin de noter les problématiques rencontrées et de donner un certain fil de développement pour venir à bout de la problématique posée.
Ce qui reviendra à proposer des axes/questions sur les manipulations de cette maquette de TP.

== Note valable pour toutes les semaines ==

'''[[Si un point vous semble imprécis, veuillez vous reporter aux détails fournis en annexe.]]'''

== 1éme semaine: (du 27/01/2014 au 01/02/2014) ==

Séance du 05/02/2014 :

Pour bien comprendre les différentes choses à réaliser, on a refait les manipulations vues en TP. On a, pour cela utiliser la maquette didactique TIMS pour générer différent type de modulation:

-la modulation en 4,8,16PSK (on obtient une constellation en forme de cercle).

-La modulation en 4,8,16QAM (on obtient une constellation avec un carré, ou deux: de différentes tailles).

On a très vite dégagé la nécessité de réaliser un montage générateur de tous les mots numériques possibles.
On a donc fait un programme sur arduino qui équivaut au générateur pseudo aléatoire.
Celui-ci est directement inspiré du montage que l'on a réalisé l'année dernière en conception de circuit électronique.

Séance du 06/02/2014 :

Lors de cette séance on a exploré toutes les possibilités concernant la communication entre la maquette/carte, car cela pour avoir une influence non négligeable sur le choix de la carte F.P.G.A. et du design de la maquette.

On a donc aussi fait des recherches concernant les possibilités de communications et les blocs I.P. (Intellectual Properties) permettant de programmer un F.P.G.A.

Et enfin, on a eu une discussion avec un responsable technique pour ce qui de la C.E.M. (Compatibilité Electro-Magnétique)

== 2éme semaine: (du 03/02/2014 au 08/02/2014) ==

Réflexion sur les possibilités possibles et offertes par le sujet pour ce qui est des parties de communications entre la maquette en interne et de son environnement.

[[Fichier:P34_2013_2014_schéma_principe_carte_semaine_2.PNG|300px|thumb|center|Maquette en interne/externe.]]

N'ayant jamais utilisé d'autre carte que la Nanoboard, on s'est attelé à faire des recherches sur la manière de procéder pour programmer une carte F.P.G.A., il se trouve que chaque carte de développement à ses propres manières pour être programmé.

On a pris le soin de noter toutes les questions concernant le F.P.G.A. pour un intervenant industriel qui assura un cours la semaine prochaine.

== 3éme semaine: (du 10/02/2014 au 15/02/2014) ==

Ayant les oscillateurs commandables en tension, on a pu commencer à faire une manipulation avec les composants Mini-Circuit.

Mais après un problème suite à une manipulation l'un des VCOs ne fonctionne plus.

Ce qui nous amène à penser qu'il sera judicieux de prévoir une alimentation au niveau de la carte.

Celle-ci devra être inférieure ou égale à la tension maximale d'alimentation du composant (ceux-ci étant très sensible).

Questions/Réponses:

Comment fait-on pour programmer une carte F.P.G.A. est-ce que la programmation se fait "in situe" ? (in situe : c'est à dire sur la carte elle-même)
Oui, c'est ce qui est utilisé, via un câble JTAG.

Est-ce possible faire une interface USB pour permettre à un ordinateur de communiquer avec la maquette/carte via un F.P.G.A. ? Oui.

Est-ce que la gestion de l'interface Ethernet est envisageable ? Oui.

Pour une communication en protocole UDP avec un ordinateur via une liaison Ethernet, est-ce qu'il y a d'autres façons que d'utiliser un "SoftCore" ?

Oui, il existe aussi bien en Software, qu'en Hardware.

== 4éme semaine: (du 17/02/2014 au 22/02/2014) ==

On a donc repris l'idée de la 2éme semaine.

Après avoir mis en place un cahier des charges au niveau des qualités, bande passante minimale.

Nous avons fait des recherches sur les composants à utiliser (i.e. CAN, CAN, ...)

Ce qui nous a permis après une édition rapide de schéma électrique (schematic) d'avoir une idée du nombre de pins dont nous aurons besoin sur une carte FPGA afin de réaliser le projet.

Après prospection, il se trouve que nous nous dirigerions vers la carte Digilent Spartan 3, dont l'école était déjà en possession.

Donc nous nous sommes attelés à faire des recherches et des essais sur cette carte et pour notamment trouver un moyen de la faire fonctionner.

== 5éme semaine: (du 03/03/2014 au 08/03/2014) ==

Tout d'abord, après plusieurs heures de recherches et d'essai infructueux, on a fini par trouver les drivers pour le câble USB diligent.

Et donc ainsi avoir un fonctionnement de la communication via le câble JTAG plus propice au fonctionnement de la carte.

On a pu enfin se conforter sur une partie des composants et des dimensionnements pour certains d'entre eux (valeur de résistance,capacité...)

Schématics: Édition de multiple bibliothèque pour Altium, intégrant à la fois schématics et leur empreinte PCB associée.

(On a pu constater qu'une interface 3v3 5v n'est pas forcement nécessaire pour assurer le bon fonctionnement entre deux cartes avec des tensions d'alimentation différentes.)

== 6éme semaine: (du 10/03/2014 au 15/03/2014) ==

On a pu enfin se conforter sur l'ensemble des composants et des choix de régulateur et utilisation d'autre diode Zener.

On trouvera le schéma intégral avec les bibliothèques nécessaires dans la semaine 5.

Cette semaine a été dédiée à l'envoi de la commande des composants au sein du magasin de l'école et du fournisseur.

Après envoi de la commande, il se trouve que le projet a changé d'objectif principal.

Il est maintenant prioritaire de réaliser un code VHDL capable d'évaluer la vitesse de transmission numérique du côté récepteur.

== 7éme semaine: (du 17/03/2014 au 22/03/2014) ==

Pour cette semaine, on s'est concentré sur la réalisation d'un générateur pseudo aléatoire en interne au FPGA.

On réalisera une échelle de résistance afin de réaliser une conversion numérique analogique afin de l'envoyer sur la chaine de transmission.

Ce code de "base" nous permettra de réaliser un flux de données fictif pour obtenir toutes les combinaisons récupérant le résultat du bus.

[[MédiaP34_2013_2014_gene_pseudo_19_03_2014_6_semaine_7.zip|Archive contenant le projet ISE Xilinx.]]

[[Fichier:P34_2013_2014_rtl_semaine_7.PNG|300px|thumb|center|extrait du schéma RTL, on peut y voir clairement les inférences de Xilinx.]]

Ce schéma a deux entrées et une sortie, une entrée d'initialisation, une horloge et une sortie pour la trame en pseudo aléatoire.

On fera l'essai sur la carte lors de la semaine suivante.

== 8éme semaine: (du 24/03/2014 au 26/03/2014) ==

Après le premier test, on pourrait penser que l'on récupère du bruit en sortie de la carte:

[[Fichier:P34_2013_2014_DSC_0024_1_probleme_d_overshoot_semaine_8.jpg|300px|thumb|center|Overshoot.]]

Pour pouvoir remédier à ce problème, on a fait une prédivision de l'horloge

[[Fichier:P34_2013_2014_DSC_0037_1_div_freq_semaine_8.jpg|300px|thumb|center|Overshoot après division.]]

[[Fichier:P34_2013_2014_DSC_0039_1_div_freq_zoom_semaine_8.jpg|300px|thumb|center|Overshoot après division (Zoom).]]

Archive contenant toutes les modifications:

[[Média:P34_2013_2014_gene_pseudo_26_03_2014_2_semaine_8.zip|VHDL Semaine 8.]]

On a trouvé un moyen de faire un CNA facilement, via une "échelle dite R-2R". [[http://www.uchobby.com/index.php/2008/01/08/arduino-audio-dac-options/|Pour le réseau R 2R.]]

Il faut encore modifier le VHDL pour pouvoir l'exploiter et ainsi générer une constellation.

== 9éme semaine: (du 28/03/2014 au 03/04/2014) ==

On a pris donc le soin de modifier le VHDL:

[[Média:P34_2013_2014_gene_pseudo_31_03_2014_1_semaine_9.zip|VHDL semaine 9]]

Ce VHDL à été mis à jour, avec deux entrées (initialisation et une horloge) et un bus de sortie (8 bits), avec les trames pseudoaléatoires.

On envoie ces signaux sur deux C.N.A.s (4 bits chacun) pour générer deux signaux I et Q, on peut voir une constellation se dessiner en mode X-Y.

[[Fichier:P34_2013_2014_DSC_0072_1_Montage_entier_4qam_semaine_9.jpg|300px|thumb|center|Montage avec constellations 4QAM.]]

D'autres constellations réalisées sont disponibles en annexe. On peut monter jusqu'à une constellation de 256 points (2^4*2^4).

On a réalisé le montage complet de toute la chaine de transmission. Il se trouve que la Boucle à Verrouillage de Phase (ou appellée PLL, Phase Loop Locker) ne se verrouille pas sur la porteuse du signal que l'on souhaite récupéré, de ce fait on ne peut pas récupérer les signaux I et Q.

== 10éme semaine: (du 07/04/2014 au 10/04/2014) ==

On a réalisé le montage que l'on évoquait en semaine 9:

[[Fichier:P34_2013_2014_DSC_0027_montage_realisee_semaine_10.jpg|center|thumb|300px|Montage pour améliorer la PLL.]]

Il se trouve qu’après un réglage précis de la tension d'offset permettant d'être un proche de la fréquence à capturer on obtient:

[[Fichier:P34_2013_2014_DSC_0025_PLL_non_verrouillage_semaine_10.jpg|center|thumb|300px|Signaux I/Q après ajout du montage.]]

= Annexes =

== Annexe A: Détails techniques des semaines ==

=== 1éme semaine: (du 27/01/2014 au 01/02/2014) ===

Après on a réfléchi sur la potentielle conception/utilisation d'une carte FPGA.
Il sera judicieux de ne pas se précipiter sur le schéma et la conception/utilisation d'une carte FPGA, sans avoir, au préalable fait le VHDL et le testez avec un banc de test virtuel.
L'intérêt et de mettre en valeur la nécessité ou non de certains signaux pour le schéma de la carte.
On va mettre en oeuvre les connaissances acquises au S7 en VHDL (en TP de Circuit Numérique Programmble).

Pour ce qui est de l'Arduino, on a répondu aux interrogations suivantes (certaines de ces questions paraissent triviales, mais on préfère éviter les surprises):

Quelle est la vitesse maximale de la communication série de l'Arduino ?
-115200bauds

Est-ce que, un programme de type "Analog Write" est-il une vraie sortie analogique ?

-Non, c'est juste une PWM. Elle sera exploitable pour faire les signales I/Q mais très contraignantes, car il faudra filtré le signal, et ce sera beaucoup trop lent (du au fait que la modulation est faite au alentour de 850Mhz), le FPGA sera un passage obligé cela ouvrira les portes d'un plus grand débit.

==== Manipulation réalisée sur la maquette TIMS : ====

On a fait un des montages présentés dans l'ouvrage "Volume D1 Fundamental Digital Experiments" dans le but de visualiser l’objectif à atteindre.

On obtient la constellation suivante (16QAM):

[[Fichier:P34_2013_2014_constelation_tims_semaine_1.PNG|300px|thumb|center|Constellation visualisée en mode X-Y.]]

Ce qui correspond à deux signaux en visualisation temporelle de cette forme :

[[Fichier:P34_2013_2014_constelation_temporelle_tims_semaine_1.PNG|300px|thumb|center|Signaux I et Q. (Image très floutée, à remplacer)]]

On pourra facilement obtenir le même résultat en générant un bus de trame pseudo aléatoire et en l'injectant dans un C.N.A. (Conversion Numérique Analogique)

==== Code Arduino réalisé: ====

[[Fichier:P34_2013_2014_schema_electronique_generateur_pseudo_aleatoire.png|300px|thumb|center|Schéma électronique du générateur pseudo aléatoire.]]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_chrono_simule.PNG|300px|thumb|center|Résultat de la simulation du générateur pseudo aléatoire (on a eu la même chose en pratique).]]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_arduino.jpg|300px|thumb|center|Resultat avec le générateur pseudo aléatoire "émuler" avec l'Arduino.]]

Comparaison carte réelle/résultat Arduino:

C'était exactement les signaux attendus (même s'il y un décalage a par rapport à l'original).

On aura bien pour une QPSK (4PSK) tous les couples (ie 00,01,11 et 10).

À propos de l'arduino, on pourra envisager une amélioration pour générer une séquence plus longue:

-il faudra simplement utiliser un tableau d'entier.

-paramétrer sa taille avec un N par exemple.

-N correspondra à la taille de séquence de longueur 2^N.

Voir la section "Code Arduino réalisé" en annexe B dans la semaine correspondante.

==== Possibilités de communications: ====

Exploration des possibilités de communication entre le PC et la carte en amont:

=====-> Ethernet: =====

*+ Vitesse de transmission (~10M-100M-G)bauds

*- La gestion du flux de données doit être faite par un microcontrôleur (celui-ci pourra être implémenté un bloc I.P. à l'intérieur du FPGA)

-> - Haute consommation de CLB du FPGA.

=====-> SPI (communication série): =====

*- Vitesse de transmission

-> Arduino capable de communiquer jusqu'a 115200 bauds

-> D'après certaines discussions sur des forums, on pourrait « pousser » au-delà.

=====-> I2C : =====

Communication abandonnée, ce n'est pas une priorité.

==== À propos des blocs I.P.: ====

En consultant les ordinateurs et en s'appuyant des T.P.s de CNP, on constate que les blocs suivants existent:

- Xilinx Microblaze/Xilinx Power PC ("µP FPGA")

-> Est-ce possible d'utiliser ces blocs I.P. pour programmer un FPGA sur une carte autre que la Nanoboard ? Comment ?

- EMACx (Ethernet Media Acess Control)(:lien physique entre processeurs et "standart Physical Layer device IEEE802.3")

===== Conception de la carte: =====

L'idéal est de se documenter sur la Compatibilité électromagnétique.

=== 2éme semaine: (du 03/02/2014 au 08/02/2014) ===

(Rien pour l'annexe.)

=== 3éme semaine: (du 10/02/2014 au 15/02/2014) ===

Lors de cette semaine, après avoir eu le problème de manipulation, nous avons pu prendre connaissance d'un certain montage qui s’avéra utile pour la conception de la carte/maquette.

[[Fichier:P34_2013_2014_schéma_limiteur_de_courant_semaine_3.PNG|300px|thumb|center|Schéma limiteur de courant.]]

On remarquera que ce montage se retrouve dans la partie "typical application" de la documentation technique du 7805.

=== 4éme semaine: (du 17/02/2014 au 22/02/2014) ===

On souhaite pouvoir réaliser une communication unidirectionnelle ou même transmettre un signal audio ce qui nous contraint à une bande passante minimale de 48kHz, on prendra 200kHz (pour être bien au-delà de la condition du théorème de Shannon): le but serait donc de brancher par exemple une source audio quelconque puis de la transmettre à travers la maquette et de la recomposer en fin de chaine.

Après édition rapide du schéma, on en dégage qu'il nous faudra un minimum d'environ 50 entrées/sorties. Mais ceci ce nombre sera très probablement revu à la hausse lors de prochaine séance.

Voici la carte que l'on utilisera dans la suite du projet:

[[Fichier:P34_2013_2014_S3BOARD-top-400_semaine_4.gif|300px|thumb|center|Digilent Spartan 3.]]

=== 5éme semaine: (du 03/03/2014 au 08/03/2014) ===

Lien vers le Design complet avec les librairies incluses (on remarquera qu'il serait judicieux d’installer toutes les librairies avant d’essayer d'ouvrir le schéma)

A notez aussi que l'on trouvera des reliques de feuilles Excel permettant de trouver rapidement des ratios dans la série E12.

[[Média:P34_2013_2014_Design_pcb_plus_librairies_semaine_5_6.zip|Schéma + Bibliothèques.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.pdf|Schéma en PDF.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.png|Schéma au format A2.]]

=== 6éme semaine: (du 10/03/2014 au 15/03/2014) ===

(Rien pour l'annexe.)

=== 7éme semaine: (du 17/03/2014 au 22/03/2014) ===

(Rien pour l'annexe.)

=== 8éme semaine: (du 24/03/2014 au 26/03/2014) ===

(Rien pour l'annexe.)

=== 9éme semaine: (du 28/03/2014 au 03/04/2014) ===

[[Fichier:P34_2013_2014_DSC_0061_1_r_2r_semaine_9.jpg|center|thumb|300px|Le réseau R-2R.]]

[[Fichier:P34_2013_2014_DSC_0062_1_4QAM_semaine_9.jpg|center|thumb|300px|4QAM.]]

[[Fichier:P34_2013_2014_DSC_0066_1_16QAM_semaine_9.jpg|center|thumb|300px|16QAM.]]

[[Fichier:P34_2013_2014_DSC_0069_1_64QAM_semaine_9.jpg|center|thumb|300px|64QAM.]]

Pas de photos pour la constellation à 256 points, mais elle a été réalisée.

Pour ce qui est du montage, malgré que la P.L.L., on a un signal d'erreur après filtrage :

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Chaine 1: Vtune (commande du V.C.O.)/Chaine 2: "erreur" de commande]]

Ce qui met en valeur immédiatement deux problèmes majeurs:

La chaine fonctionne sur le papier, mais lors de sa mise en pratique, il faut penser à mettre une tension d'offset et aussi réaliser une amplification de l'erreur pour avoir des grandeurs de commande adaptée au Vtune du V.C.O..

On propose l'amélioration suivante (qui sera réalisé à la prochaine séance):

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Proposition de voie d'amélioration.]]

On remarquera que les valeurs des résistances et des capacités on était choisi pour permettre un fonctionnement correct des A.O. (Amplificateur Opérationnel), mais pas pour ce qui de l'asservissement de la boucle par manque de temps.

A la fin de cette, on a eu à démonter le montage à cause de contraintes concernant les Mini-circuits (car utilisé en travaux pratiques).

=== 10éme semaine: (du 07/04/2014 au 10/04/2014) ===

Spectres des signaux de la chaine de transmission:

[[Fichier:P34_2013_2014_DSC_0001_allure_spectre_reception_semaine_10.jpg|center|thumb|300px|Spectre en réception.]]

Porteuse utilisée pour la modulation I/Q à environ 60MHz.

Porteuse utilisée pour le transport en fréquence à environ 810MHz:

[[Fichier:P34_2013_2014_DSC_0035_constellation_recupere_PLL_NV_semaine_10.jpg|center|thumb|300px|"Constellation" récupérée avec la PLL défectueuse (on souhaite se verrouiller sur la raie à 868MHz).]]

Question en suspens: faudrait-il utiliser un filtre passe-bande incluant 868Mhz pour pouvoir se verrouiller sur cette fréquence ?

On remarquera le fait que l'oscillateur du côté de la chaine d'émission a d'importantes non-linéarités (on peut observer à l'analyseur de spectre 3 à 4 raies aux fréquences multiples).

Ce qui donne un diagramme de constellation plutôt mauvais si l'on fait le montage suivant:

[[Fichier:P34_2013_2014_montage_non_linearite_vco_constellation_semaine_10.PNG|center|thumb|300px|Montage réalisée.]]

[[Fichier:P34_2013_2014_sortie_montage_non_linearite_semaine_10.PNG|center|thumb|300px|La constellation 4QAM est attendue, on est loin du résultat attendu (aucune photo n'a était réalisé d'ou le dessin).]]

== Annexe B: Digilent Spartan 3 ==

=== Procédure pour faire fonctionner la carte Digilent Spartan 3: ===

Ne connectez pas de connecteur JTAG pendant les installations. Redémarrez après chaque installation.

Tout d'abord, il faut savoir que le l'ISE Webpack 14.6 fonctionne avec la carte (n'utilisez pas la 14.7, elle ne supporte pas la génération spartan 3 !):

Installez donc l'ISE WebPack 14.6 (ou antérieur à condition que celle-ci soit supérieur à la 7.1i (d'après leur documentation))

(voir lien utile sur Xilinx)

Une fois l'installation de l'ISE terminé, faites en sorte d'avoir celui que soit opérationnel (la licence est gratuite !).

Installez la "library" ADEPT 2.3 voir le lien utile.

Après vous n'avez plus qu'a utilisez ISE Xilinx normalement et vous serez capable de reconnaitre la carte via la liaison JTAG, et de le programmer.

=== Liens utiles: ===

Lien constructeur/vendeur (avec ressources utiles en bas de la page):

http://www.digilentinc.com/Products/Detail.cfm?Prod=S3BOARD

Lien "Library" pour le câble USB digilent:

http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,66,69&Prod=ADEPT

Lien Xilinx (Pour l'ISE 14.6):

http://www.xilinx.com/products/design-tools/ise-design-suite/index.htm

Lien Xilinx (Pour les versions antérieures veuillez faire attention au système d'exploitation, votre architecture matérielle et le FPGA cible):

(Les informations de compatibilité son sur la page suivante:) (mots clés: xilinx classic(s))

http://www.xilinx.com/tools/classics.htm

=== Procédure pour faire une programmation en volatile: ===

Générer le bitstream, et le charger.

=== Procédure pour faire une programmation en "non"-volatile: ===

Générer le bitstream et l'utiliser pour générer un .mcs qui vous permettra d'inscrire le programme dans la mémoire (E?)PROM.

On remarquera que la programmation en non volatile est utile pour faire un remise à zéro et recharger le contenu de l'(E?)PROM, mais semble être sensible au débranchement de l'adaptateur d'alimentation de la carte.

=== Exemple de programmation: ===

Voir le lien digilent pour ceci dans cette annexe.

Fichier:Rapport projet p34 s8 6.pdf

2014-04-14T21:19:14Z

Jvaessen :

Modem pour le numérique

2014-04-14T21:11:53Z

Jvaessen : /* 10éme semaine: (du 07/04/2014 au 10/04/2014) */

= Modulateur et démodulateur pour communications numériques =

== Cahier des charges ==

=== Présentation générale du projet ===

Dans le cadre des TPs d'électronique et de transmission RF, nous avons découvert qu'il existe plusieurs modes de modulation, pour transmettre un signal modulant.

Celles vues en TP au S7 sont la modulation en amplitude, en fréquence, en phase, en BPSK et en QPSK.

Or les modulations en phase, en fréquence et en amplitude étant celles les plus connues, la modulation en QAM (Modulation d'Amplitude en Quadrature) est quant à elle moins connue, mais tout aussi utilisées:

-pour la TNT en 64 QAM (en France).

[[Fichier:P34_2013_2014_64qam.jpg|300px|thumb|center|Exemple de constellation 64QAM.]]

-pour le WiFi en 64-QAM ou 256-QAM (à vérifier).

Or ces deux dernières étant peu représentées au niveau des travaux pratiques, ce projet permettra de fournir un peu plus de pratique sur les modulations de type QAM (en diagramme I/Q) dans le domaine des radiofréquences (~800MHz).

(Le nombre devant le QAM indique le nombre de points dans le diagramme I/Q qu'on appelle aussi constellation)

On se réserve le droit de faire '''évoluer''' le cahier des charges a posteriori, si certaines contraintes étaient amenées à évoluer ou se préciser.

=== Objectif et intérêt du projet ===

Pour cela, on nous a fourni des modules commerciaux Mini-circuit pouvant travailler dans les radios-fréquences.

Ceux-ci permettront de mettre en place une grande partie de la chaine de transmission (voir schéma de la chaine de transmission).

[[Fichier:P34_2013_2014_Chaine_modulation.PNG|300px|thumb|center|Modulation.]]

[[Fichier:P34_2013_2014_Chaine_demodulation.PNG|300px|thumb|center|Démodulation.]]

On a tout d'abord à mettre en place une carte FPGA et/ou un dispositif permettant d'envoyer un flux de données numériques continuellement pour pouvoir visualiser le diagramme I/Q (mise en valeur du diagramme I/Q et voir même un diagramme un peu plus complexe que le BPSK ou le QPSK).

Le canal de transmission qui sera un simple fil électrique, mais pourra devenir une antenne réceptrice et émettrice si le temps imparti le permet (mise en valeur du et mesure du Bit Error Rate qui sera bien sûr différent suivant le canal de transmission).

Du côté réception ,après démodulation du signal, une remise en forme et une interprétation des données seront réalisées, celle-ci dépendra bien entendu de la provenance du flux de données (constater le succès ou l'échec d'un envoi de données).

Enfin si le temps le permets on pourra mettre en une place un système de codage de l'information avec par exemple un codage redondant permettant de corrigé l'erreur (À définir, on pourra faire constater l'efficacité d'une méthode de codage au choix).

=== Étapes/Déroulement du projet ===

De même que pour le cahier des charges, il se peut que les étapes diffèrent plus ou moins, en fonction des disponibilités, matérielles et contraintes.

==== => Caractérisation des blocs Mini-circuits et épluchage des documentations techniques====
Avant de les utiliser dans la chaine de transmission, nous avons à faire une caractérisation des blocs fournis:

-la caractérisation du VCO.

-l'étude des possibilités offerte par le modulateur (cela déterminera le nombre de points possible dans la constellation, ie savoir si l'on peut aller au-delà de la QPSK).

-la caractérisation des mélangeurs (Mixer), leurs facteurs réels de multiplication.

==== => Utilisation et exploitation des caractérisations ====
On pourra ensuite trouver les paramètres pour régler correctement dans notre chaine de transmission certains de nos sous-systèmes comme la boucle à verrouillage de phase.

==== => Génération d'un flux des données numériques ====
Comme dit précédemment, l'idéal et d'avoir un flux de données numériques transmis en permanence.
Pour cela plusieurs solutions s'offre à nous, on pourra utiliser un montage générateur pseudo aléatoire (un circuit que l'on a fait l'année dernière en Conception de Circuit Électronique).
On pourra "émuler" ce montage avec un Arduino, ou bien même le faire au moyen de la Nanoboard.
On pourra aussi transmettre des chaines de caractère en continu.

==== => Test de la chaine ====
Une fois les étapes précédentes réalisées, on pourra passer au test de la chaine de transmission. Il faudra vérifier le bon fonctionnement en aval, dedans (boucle à verrouillage de phase), et en amont de la chaine de transmission.

==== => Première mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.
Il est possible que la conception d'un dispositif soit nécessaire que ce soit pour les deux mesures du B.E.R..

==== => Antennes ====
Si toutes les étapes précédentes sont satisfaites, on pourra alors faire un canal de transmission plus intéressant, à savoir l'air.
Nous passerons alors à la conception des antennes, émettrice et réceptrice.

==== => Deuxième mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.

==== => Codage de l'information et correction d'erreur ====
En toute fin de ce projet, on pourra même mettre deux dispositifs en aval et en amont de la chaine de transmission.
On réalisera alors un codeur et un décodeur permettant de faire de la détection/correction d'erreur.

==== => Mise en place d'outil de débogage (tout au long)====
La mise en place de simples outils de débogage et primordiale, ceux-ci permettront de vérifier le bon fonctionnement de la chaine.

==== => Proposition d'un sujet de TP (tout au long) ====
Il se trouve que lors du déroulement du projet, on pourra être amené à se poser des questions au niveau des réglages de la chaine de transmission.
Or il est fort probable que les élèves qui travailleront sur ce TP pourront alors se poser les mêmes questions.
C'est pour cela qui sera judicieux de prendre soin de noter les problématiques rencontrées et de donner un certain fil de développement pour venir à bout de la problématique posée.
Ce qui reviendra à proposer des axes/questions sur les manipulations de cette maquette de TP.

== Note valable pour toutes les semaines ==

'''[[Si un point vous semble imprécis, veuillez vous reporter aux détails fournis en annexe.]]'''

== 1éme semaine: (du 27/01/2014 au 01/02/2014) ==

Séance du 05/02/2014 :

Pour bien comprendre les différentes choses à réaliser, on a refait les manipulations vues en TP. On a, pour cela utiliser la maquette didactique TIMS pour générer différent type de modulation:

-la modulation en 4,8,16PSK (on obtient une constellation en forme de cercle).

-La modulation en 4,8,16QAM (on obtient une constellation avec un carré, ou deux: de différentes tailles).

On a très vite dégagé la nécessité de réaliser un montage générateur de tous les mots numériques possibles.
On a donc fait un programme sur arduino qui équivaut au générateur pseudo aléatoire.
Celui-ci est directement inspiré du montage que l'on a réalisé l'année dernière en conception de circuit électronique.

Séance du 06/02/2014 :

Lors de cette séance on a exploré toutes les possibilités concernant la communication entre la maquette/carte, car cela pour avoir une influence non négligeable sur le choix de la carte F.P.G.A. et du design de la maquette.

On a donc aussi fait des recherches concernant les possibilités de communications et les blocs I.P. (Intellectual Properties) permettant de programmer un F.P.G.A.

Et enfin, on a eu une discussion avec un responsable technique pour ce qui de la C.E.M. (Compatibilité Electro-Magnétique)

== 2éme semaine: (du 03/02/2014 au 08/02/2014) ==

Réflexion sur les possibilités possibles et offertes par le sujet pour ce qui est des parties de communications entre la maquette en interne et de son environnement.

[[Fichier:P34_2013_2014_schéma_principe_carte_semaine_2.PNG|300px|thumb|center|Maquette en interne/externe.]]

N'ayant jamais utilisé d'autre carte que la Nanoboard, on s'est attelé à faire des recherches sur la manière de procéder pour programmer une carte F.P.G.A., il se trouve que chaque carte de développement à ses propres manières pour être programmé.

On a pris le soin de noter toutes les questions concernant le F.P.G.A. pour un intervenant industriel qui assura un cours la semaine prochaine.

== 3éme semaine: (du 10/02/2014 au 15/02/2014) ==

Ayant les oscillateurs commandables en tension, on a pu commencer à faire une manipulation avec les composants Mini-Circuit.

Mais après un problème suite à une manipulation l'un des VCOs ne fonctionne plus.

Ce qui nous amène à penser qu'il sera judicieux de prévoir une alimentation au niveau de la carte.

Celle-ci devra être inférieure ou égale à la tension maximale d'alimentation du composant (ceux-ci étant très sensible).

Questions/Réponses:

Comment fait-on pour programmer une carte F.P.G.A. est-ce que la programmation se fait "in situe" ? (in situe : c'est à dire sur la carte elle-même)
Oui, c'est ce qui est utilisé, via un câble JTAG.

Est-ce possible faire une interface USB pour permettre à un ordinateur de communiquer avec la maquette/carte via un F.P.G.A. ? Oui.

Est-ce que la gestion de l'interface Ethernet est envisageable ? Oui.

Pour une communication en protocole UDP avec un ordinateur via une liaison Ethernet, est-ce qu'il y a d'autres façons que d'utiliser un "SoftCore" ?

Oui, il existe aussi bien en Software, qu'en Hardware.

== 4éme semaine: (du 17/02/2014 au 22/02/2014) ==

On a donc repris l'idée de la 2éme semaine.

Après avoir mis en place un cahier des charges au niveau des qualités, bande passante minimale.

Nous avons fait des recherches sur les composants à utiliser (i.e. CAN, CAN, ...)

Ce qui nous a permis après une édition rapide de schéma électrique (schematic) d'avoir une idée du nombre de pins dont nous aurons besoin sur une carte FPGA afin de réaliser le projet.

Après prospection, il se trouve que nous nous dirigerions vers la carte Digilent Spartan 3, dont l'école était déjà en possession.

Donc nous nous sommes attelés à faire des recherches et des essais sur cette carte et pour notamment trouver un moyen de la faire fonctionner.

== 5éme semaine: (du 03/03/2014 au 08/03/2014) ==

Tout d'abord, après plusieurs heures de recherches et d'essai infructueux, on a fini par trouver les drivers pour le câble USB diligent.

Et donc ainsi avoir un fonctionnement de la communication via le câble JTAG plus propice au fonctionnement de la carte.

On a pu enfin se conforter sur une partie des composants et des dimensionnements pour certains d'entre eux (valeur de résistance,capacité...)

Schématics: Édition de multiple bibliothèque pour Altium, intégrant à la fois schématics et leur empreinte PCB associée.

(On a pu constater qu'une interface 3v3 5v n'est pas forcement nécessaire pour assurer le bon fonctionnement entre deux cartes avec des tensions d'alimentation différentes.)

== 6éme semaine: (du 10/03/2014 au 15/03/2014) ==

On a pu enfin se conforter sur l'ensemble des composants et des choix de régulateur et utilisation d'autre diode Zener.

On trouvera le schéma intégral avec les bibliothèques nécessaires dans la semaine 5.

Cette semaine a été dédiée à l'envoi de la commande des composants au sein du magasin de l'école et du fournisseur.

Après envoi de la commande, il se trouve que le projet a changé d'objectif principal.

Il est maintenant prioritaire de réaliser un code VHDL capable d'évaluer la vitesse de transmission numérique du côté récepteur.

== 7éme semaine: (du 17/03/2014 au 22/03/2014) ==

Pour cette semaine, on s'est concentré sur la réalisation d'un générateur pseudo aléatoire en interne au FPGA.

On réalisera une échelle de résistance afin de réaliser une conversion numérique analogique afin de l'envoyer sur la chaine de transmission.

Ce code de "base" nous permettra de réaliser un flux de données fictif pour obtenir toutes les combinaisons récupérant le résultat du bus.

[[MédiaP34_2013_2014_gene_pseudo_19_03_2014_6_semaine_7.zip|Archive contenant le projet ISE Xilinx.]]

[[Fichier:P34_2013_2014_rtl_semaine_7.PNG|300px|thumb|center|extrait du schéma RTL, on peut y voir clairement les inférences de Xilinx.]]

Ce schéma a deux entrées et une sortie, une entrée d'initialisation, une horloge et une sortie pour la trame en pseudo aléatoire.

On fera l'essai sur la carte lors de la semaine suivante.

== 8éme semaine: (du 24/03/2014 au 26/03/2014) ==

Après le premier test, on pourrait penser que l'on récupère du bruit en sortie de la carte:

[[Fichier:P34_2013_2014_DSC_0024_1_probleme_d_overshoot_semaine_8.jpg|300px|thumb|center|Overshoot.]]

Pour pouvoir remédier à ce problème, on a fait une prédivision de l'horloge

[[Fichier:P34_2013_2014_DSC_0037_1_div_freq_semaine_8.jpg|300px|thumb|center|Overshoot après division.]]

[[Fichier:P34_2013_2014_DSC_0039_1_div_freq_zoom_semaine_8.jpg|300px|thumb|center|Overshoot après division (Zoom).]]

Archive contenant toutes les modifications:

[[Média:P34_2013_2014_gene_pseudo_26_03_2014_2_semaine_8.zip|VHDL Semaine 8.]]

On a trouvé un moyen de faire un CNA facilement, via une "échelle dite R-2R". [[http://www.uchobby.com/index.php/2008/01/08/arduino-audio-dac-options/|Pour le réseau R 2R.]]

Il faut encore modifier le VHDL pour pouvoir l'exploiter et ainsi générer une constellation.

== 9éme semaine: (du 28/03/2014 au 03/04/2014) ==

On a pris donc le soin de modifier le VHDL:

[[Média:P34_2013_2014_gene_pseudo_31_03_2014_1_semaine_9.zip|VHDL semaine 9]]

Ce VHDL à été mis à jour, avec deux entrées (initialisation et une horloge) et un bus de sortie (8 bits), avec les trames pseudoaléatoires.

On envoie ces signaux sur deux C.N.A.s (4 bits chacun) pour générer deux signaux I et Q, on peut voir une constellation se dessiner en mode X-Y.

[[Fichier:P34_2013_2014_DSC_0072_1_Montage_entier_4qam_semaine_9.jpg|300px|thumb|center|Montage avec constellations 4QAM.]]

D'autres constellations réalisées sont disponibles en annexe. On peut monter jusqu'à une constellation de 256 points (2^4*2^4).

On a réalisé le montage complet de toute la chaine de transmission. Il se trouve que la Boucle à Verrouillage de Phase (ou appellée PLL, Phase Loop Locker) ne se verrouille pas sur la porteuse du signal que l'on souhaite récupéré, de ce fait on ne peut pas récupérer les signaux I et Q.

== 10éme semaine: (du 07/04/2014 au 10/04/2014) ==

On a réalisé le montage que l'on évoquait en semaine 9:

[[Fichier:P34_2013_2014_DSC_0027_montage_realisee_semaine_10.jpg|center|thumb|300px|Montage pour améliorer la PLL.]]

Il se trouve qu’après un réglage précis de la tension d'offset permettant d'être un proche de la fréquence à capturer on obtient:

[[Fichier:P34_2013_2014_DSC_0025_PLL_non_verrouillage_semaine_10.jpg|center|thumb|300px|Signaux I/Q après ajout du montage.]]

= Annexes =

== Annexe A: Détails techniques des semaines ==

=== 1éme semaine: (du 27/01/2014 au 01/02/2014) ===

Après on a réfléchi sur la potentielle conception/utilisation d'une carte FPGA.
Il sera judicieux de ne pas se précipiter sur le schéma et la conception/utilisation d'une carte FPGA, sans avoir, au préalable fait le VHDL et le testez avec un banc de test virtuel.
L'intérêt et de mettre en valeur la nécessité ou non de certains signaux pour le schéma de la carte.
On va mettre en oeuvre les connaissances acquises au S7 en VHDL (en TP de Circuit Numérique Programmble).

Pour ce qui est de l'Arduino, on a répondu aux interrogations suivantes (certaines de ces questions paraissent triviales, mais on préfère éviter les surprises):

Quelle est la vitesse maximale de la communication série de l'Arduino ?
-115200bauds

Est-ce que, un programme de type "Analog Write" est-il une vraie sortie analogique ?

-Non, c'est juste une PWM. Elle sera exploitable pour faire les signales I/Q mais très contraignantes, car il faudra filtré le signal, et ce sera beaucoup trop lent (du au fait que la modulation est faite au alentour de 850Mhz), le FPGA sera un passage obligé cela ouvrira les portes d'un plus grand débit.

==== Manipulation réalisée sur la maquette TIMS : ====

On a fait un des montages présentés dans l'ouvrage "Volume D1 Fundamental Digital Experiments" dans le but de visualiser l’objectif à atteindre.

On obtient la constellation suivante (16QAM):

[[Fichier:P34_2013_2014_constelation_tims_semaine_1.PNG|300px|thumb|center|Constellation visualisée en mode X-Y.]]

Ce qui correspond à deux signaux en visualisation temporelle de cette forme :

[[Fichier:P34_2013_2014_constelation_temporelle_tims_semaine_1.PNG|300px|thumb|center|Signaux I et Q. (Image très floutée, à remplacer)]]

On pourra facilement obtenir le même résultat en générant un bus de trame pseudo aléatoire et en l'injectant dans un C.N.A. (Conversion Numérique Analogique)

==== Code Arduino réalisé: ====

[[Fichier:P34_2013_2014_schema_electronique_generateur_pseudo_aleatoire.png|300px|thumb|center|Schéma électronique du générateur pseudo aléatoire.]]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_chrono_simule.PNG|300px|thumb|center|Résultat de la simulation du générateur pseudo aléatoire (on a eu la même chose en pratique).]]

[code]
/*A peut-être supprimer*/
#include <avr/io.h>
#include <util/delay.h>

void output_init(void){
DDRB |= 0x02; // PIN 8,9 sont les deux sorties.
}

int main(void){
int r1=1,r2=0,r3=0,r4=0,r5=0,retard=0;
PORTB=0x00;
while(1)
{
r5=r4;//chaque affectation représente une recopie de la bascule sur le "front montant", ici c'est simplement l’exécution du code.
r4=r3;
r3=r2;
r2=r1;
r1=r4^r5;
PORTB=0x01*r1+0x02*retard;//écriture des signaux
_delay_ms(10);//le "front montant", ce qui permet de faire un genre d'horloge.
retard=r5;//déphasage du signal
}
return 0;
}
[/code]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_arduino.jpg|300px|thumb|center|Resultat avec le générateur pseudo aléatoire "émuler" avec l'Arduino.]]

Comparaison carte réelle/résultat Arduino:

C'était exactement les signaux attendus (même s'il y un décalage a par rapport à l'original).

On aura bien pour une QPSK (4PSK) tous les couples (ie 00,01,11 et 10).

À propos de l'arduino, on pourra envisager une amélioration pour générer une séquence plus longue:

-il faudra simplement utiliser un tableau d'entier.

-paramétrer sa taille avec un N par exemple.

-N correspondra à la taille de séquence de longueur 2^N.

Voir la section "Code Arduino réalisé" en annexe B dans la semaine correspondante.

==== Possibilités de communications: ====

Exploration des possibilités de communication entre le PC et la carte en amont:

=====-> Ethernet: =====

*+ Vitesse de transmission (~10M-100M-G)bauds

*- La gestion du flux de données doit être faite par un microcontrôleur (celui-ci pourra être implémenté un bloc I.P. à l'intérieur du FPGA)

-> - Haute consommation de CLB du FPGA.

=====-> SPI (communication série): =====

*- Vitesse de transmission

-> Arduino capable de communiquer jusqu'a 115200 bauds

-> D'après certaines discussions sur des forums, on pourrait « pousser » au-delà.

=====-> I2C : =====

Communication abandonnée, ce n'est pas une priorité.

==== À propos des blocs I.P.: ====

En consultant les ordinateurs et en s'appuyant des T.P.s de CNP, on constate que les blocs suivants existent:

- Xilinx Microblaze/Xilinx Power PC ("µP FPGA")

-> Est-ce possible d'utiliser ces blocs I.P. pour programmer un FPGA sur une carte autre que la Nanoboard ? Comment ?

- EMACx (Ethernet Media Acess Control)(:lien physique entre processeurs et "standart Physical Layer device IEEE802.3")

===== Conception de la carte: =====

L'idéal est de se documenter sur la Compatibilité électromagnétique.

=== 2éme semaine: (du 03/02/2014 au 08/02/2014) ===

(Rien pour l'annexe.)

=== 3éme semaine: (du 10/02/2014 au 15/02/2014) ===

Lors de cette semaine, après avoir eu le problème de manipulation, nous avons pu prendre connaissance d'un certain montage qui s’avéra utile pour la conception de la carte/maquette.

[[Fichier:P34_2013_2014_schéma_limiteur_de_courant_semaine_3.PNG|300px|thumb|center|Schéma limiteur de courant.]]

On remarquera que ce montage se retrouve dans la partie "typical application" de la documentation technique du 7805.

=== 4éme semaine: (du 17/02/2014 au 22/02/2014) ===

On souhaite pouvoir réaliser une communication unidirectionnelle ou même transmettre un signal audio ce qui nous contraint à une bande passante minimale de 48kHz, on prendra 200kHz (pour être bien au-delà de la condition du théorème de Shannon): le but serait donc de brancher par exemple une source audio quelconque puis de la transmettre à travers la maquette et de la recomposer en fin de chaine.

Après édition rapide du schéma, on en dégage qu'il nous faudra un minimum d'environ 50 entrées/sorties. Mais ceci ce nombre sera très probablement revu à la hausse lors de prochaine séance.

Voici la carte que l'on utilisera dans la suite du projet:

[[Fichier:P34_2013_2014_S3BOARD-top-400_semaine_4.gif|300px|thumb|center|Digilent Spartan 3.]]

=== 5éme semaine: (du 03/03/2014 au 08/03/2014) ===

Lien vers le Design complet avec les librairies incluses (on remarquera qu'il serait judicieux d’installer toutes les librairies avant d’essayer d'ouvrir le schéma)

A notez aussi que l'on trouvera des reliques de feuilles Excel permettant de trouver rapidement des ratios dans la série E12.

[[Média:P34_2013_2014_Design_pcb_plus_librairies_semaine_5_6.zip|Schéma + Bibliothèques.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.pdf|Schéma en PDF.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.png|Schéma au format A2.]]

=== 6éme semaine: (du 10/03/2014 au 15/03/2014) ===

(Rien pour l'annexe.)

=== 7éme semaine: (du 17/03/2014 au 22/03/2014) ===

(Rien pour l'annexe.)

=== 8éme semaine: (du 24/03/2014 au 26/03/2014) ===

(Rien pour l'annexe.)

=== 9éme semaine: (du 28/03/2014 au 03/04/2014) ===

[[Fichier:P34_2013_2014_DSC_0061_1_r_2r_semaine_9.jpg|center|thumb|300px|Le réseau R-2R.]]

[[Fichier:P34_2013_2014_DSC_0062_1_4QAM_semaine_9.jpg|center|thumb|300px|4QAM.]]

[[Fichier:P34_2013_2014_DSC_0066_1_16QAM_semaine_9.jpg|center|thumb|300px|16QAM.]]

[[Fichier:P34_2013_2014_DSC_0069_1_64QAM_semaine_9.jpg|center|thumb|300px|64QAM.]]

Pas de photos pour la constellation à 256 points, mais elle a été réalisée.

Pour ce qui est du montage, malgré que la P.L.L., on a un signal d'erreur après filtrage :

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Chaine 1: Vtune (commande du V.C.O.)/Chaine 2: "erreur" de commande]]

Ce qui met en valeur immédiatement deux problèmes majeurs:

La chaine fonctionne sur le papier, mais lors de sa mise en pratique, il faut penser à mettre une tension d'offset et aussi réaliser une amplification de l'erreur pour avoir des grandeurs de commande adaptée au Vtune du V.C.O..

On propose l'amélioration suivante (qui sera réalisé à la prochaine séance):

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Proposition de voie d'amélioration.]]

On remarquera que les valeurs des résistances et des capacités on était choisi pour permettre un fonctionnement correct des A.O. (Amplificateur Opérationnel), mais pas pour ce qui de l'asservissement de la boucle par manque de temps.

A la fin de cette, on a eu à démonter le montage à cause de contraintes concernant les Mini-circuits (car utilisé en travaux pratiques).

=== 10éme semaine: (du 07/04/2014 au 10/04/2014) ===

Spectres des signaux de la chaine de transmission:

[[Fichier:P34_2013_2014_DSC_0001_allure_spectre_reception_semaine_10.jpg|center|thumb|300px|Spectre en réception.]]

Porteuse utilisée pour la modulation I/Q à environ 60MHz.

Porteuse utilisée pour le transport en fréquence à environ 810MHz:

[[Fichier:P34_2013_2014_DSC_0035_constellation_recupere_PLL_NV_semaine_10.jpg|center|thumb|300px|"Constellation" récupérée avec la PLL défectueuse (on souhaite se verrouiller sur la raie à 868MHz).]]

Question en suspens: faudrait-il utiliser un filtre passe-bande incluant 868Mhz pour pouvoir se verrouiller sur cette fréquence ?

On remarquera le fait que l'oscillateur du côté de la chaine d'émission a d'importantes non-linéarités (on peut observer à l'analyseur de spectre 3 à 4 raies aux fréquences multiples).

Ce qui donne un diagramme de constellation plutôt mauvais si l'on fait le montage suivant:

[[Fichier:P34_2013_2014_montage_non_linearite_vco_constellation_semaine_10.PNG|center|thumb|300px|Montage réalisée.]]

[[Fichier:P34_2013_2014_sortie_montage_non_linearite_semaine_10.PNG|center|thumb|300px|La constellation 4QAM est attendue, on est loin du résultat attendu (aucune photo n'a était réalisé d'ou le dessin).]]

== Annexe B: Digilent Spartan 3 ==

=== Procédure pour faire fonctionner la carte Digilent Spartan 3: ===

Ne connectez pas de connecteur JTAG pendant les installations. Redémarrez après chaque installation.

Tout d'abord, il faut savoir que le l'ISE Webpack 14.6 fonctionne avec la carte (n'utilisez pas la 14.7, elle ne supporte pas la génération spartan 3 !):

Installez donc l'ISE WebPack 14.6 (ou antérieur à condition que celle-ci soit supérieur à la 7.1i (d'après leur documentation))

(voir lien utile sur Xilinx)

Une fois l'installation de l'ISE terminé, faites en sorte d'avoir celui que soit opérationnel (la licence est gratuite !).

Installez la "library" ADEPT 2.3 voir le lien utile.

Après vous n'avez plus qu'a utilisez ISE Xilinx normalement et vous serez capable de reconnaitre la carte via la liaison JTAG, et de le programmer.

=== Liens utiles: ===

Lien constructeur/vendeur (avec ressources utiles en bas de la page):

http://www.digilentinc.com/Products/Detail.cfm?Prod=S3BOARD

Lien "Library" pour le câble USB digilent:

http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,66,69&Prod=ADEPT

Lien Xilinx (Pour l'ISE 14.6):

http://www.xilinx.com/products/design-tools/ise-design-suite/index.htm

Lien Xilinx (Pour les versions antérieures veuillez faire attention au système d'exploitation, votre architecture matérielle et le FPGA cible):

(Les informations de compatibilité son sur la page suivante:) (mots clés: xilinx classic(s))

http://www.xilinx.com/tools/classics.htm

=== Procédure pour faire une programmation en volatile: ===

Générer le bitstream, et le charger.

=== Procédure pour faire une programmation en "non"-volatile: ===

Générer le bitstream et l'utiliser pour générer un .mcs qui vous permettra d'inscrire le programme dans la mémoire (E?)PROM.

On remarquera que la programmation en non volatile est utile pour faire un remise à zéro et recharger le contenu de l'(E?)PROM, mais semble être sensible au débranchement de l'adaptateur d'alimentation de la carte.

=== Exemple de programmation: ===

Voir le lien digilent pour ceci dans cette annexe.

Modem pour le numérique

2014-04-14T21:08:05Z

Jvaessen : /* 10éme semaine: (du 07/04/2014 au 10/04/2014) */

= Modulateur et démodulateur pour communications numériques =

== Cahier des charges ==

=== Présentation générale du projet ===

Dans le cadre des TPs d'électronique et de transmission RF, nous avons découvert qu'il existe plusieurs modes de modulation, pour transmettre un signal modulant.

Celles vues en TP au S7 sont la modulation en amplitude, en fréquence, en phase, en BPSK et en QPSK.

Or les modulations en phase, en fréquence et en amplitude étant celles les plus connues, la modulation en QAM (Modulation d'Amplitude en Quadrature) est quant à elle moins connue, mais tout aussi utilisées:

-pour la TNT en 64 QAM (en France).

[[Fichier:P34_2013_2014_64qam.jpg|300px|thumb|center|Exemple de constellation 64QAM.]]

-pour le WiFi en 64-QAM ou 256-QAM (à vérifier).

Or ces deux dernières étant peu représentées au niveau des travaux pratiques, ce projet permettra de fournir un peu plus de pratique sur les modulations de type QAM (en diagramme I/Q) dans le domaine des radiofréquences (~800MHz).

(Le nombre devant le QAM indique le nombre de points dans le diagramme I/Q qu'on appelle aussi constellation)

On se réserve le droit de faire '''évoluer''' le cahier des charges a posteriori, si certaines contraintes étaient amenées à évoluer ou se préciser.

=== Objectif et intérêt du projet ===

Pour cela, on nous a fourni des modules commerciaux Mini-circuit pouvant travailler dans les radios-fréquences.

Ceux-ci permettront de mettre en place une grande partie de la chaine de transmission (voir schéma de la chaine de transmission).

[[Fichier:P34_2013_2014_Chaine_modulation.PNG|300px|thumb|center|Modulation.]]

[[Fichier:P34_2013_2014_Chaine_demodulation.PNG|300px|thumb|center|Démodulation.]]

On a tout d'abord à mettre en place une carte FPGA et/ou un dispositif permettant d'envoyer un flux de données numériques continuellement pour pouvoir visualiser le diagramme I/Q (mise en valeur du diagramme I/Q et voir même un diagramme un peu plus complexe que le BPSK ou le QPSK).

Le canal de transmission qui sera un simple fil électrique, mais pourra devenir une antenne réceptrice et émettrice si le temps imparti le permet (mise en valeur du et mesure du Bit Error Rate qui sera bien sûr différent suivant le canal de transmission).

Du côté réception ,après démodulation du signal, une remise en forme et une interprétation des données seront réalisées, celle-ci dépendra bien entendu de la provenance du flux de données (constater le succès ou l'échec d'un envoi de données).

Enfin si le temps le permets on pourra mettre en une place un système de codage de l'information avec par exemple un codage redondant permettant de corrigé l'erreur (À définir, on pourra faire constater l'efficacité d'une méthode de codage au choix).

=== Étapes/Déroulement du projet ===

De même que pour le cahier des charges, il se peut que les étapes diffèrent plus ou moins, en fonction des disponibilités, matérielles et contraintes.

==== => Caractérisation des blocs Mini-circuits et épluchage des documentations techniques====
Avant de les utiliser dans la chaine de transmission, nous avons à faire une caractérisation des blocs fournis:

-la caractérisation du VCO.

-l'étude des possibilités offerte par le modulateur (cela déterminera le nombre de points possible dans la constellation, ie savoir si l'on peut aller au-delà de la QPSK).

-la caractérisation des mélangeurs (Mixer), leurs facteurs réels de multiplication.

==== => Utilisation et exploitation des caractérisations ====
On pourra ensuite trouver les paramètres pour régler correctement dans notre chaine de transmission certains de nos sous-systèmes comme la boucle à verrouillage de phase.

==== => Génération d'un flux des données numériques ====
Comme dit précédemment, l'idéal et d'avoir un flux de données numériques transmis en permanence.
Pour cela plusieurs solutions s'offre à nous, on pourra utiliser un montage générateur pseudo aléatoire (un circuit que l'on a fait l'année dernière en Conception de Circuit Électronique).
On pourra "émuler" ce montage avec un Arduino, ou bien même le faire au moyen de la Nanoboard.
On pourra aussi transmettre des chaines de caractère en continu.

==== => Test de la chaine ====
Une fois les étapes précédentes réalisées, on pourra passer au test de la chaine de transmission. Il faudra vérifier le bon fonctionnement en aval, dedans (boucle à verrouillage de phase), et en amont de la chaine de transmission.

==== => Première mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.
Il est possible que la conception d'un dispositif soit nécessaire que ce soit pour les deux mesures du B.E.R..

==== => Antennes ====
Si toutes les étapes précédentes sont satisfaites, on pourra alors faire un canal de transmission plus intéressant, à savoir l'air.
Nous passerons alors à la conception des antennes, émettrice et réceptrice.

==== => Deuxième mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.

==== => Codage de l'information et correction d'erreur ====
En toute fin de ce projet, on pourra même mettre deux dispositifs en aval et en amont de la chaine de transmission.
On réalisera alors un codeur et un décodeur permettant de faire de la détection/correction d'erreur.

==== => Mise en place d'outil de débogage (tout au long)====
La mise en place de simples outils de débogage et primordiale, ceux-ci permettront de vérifier le bon fonctionnement de la chaine.

==== => Proposition d'un sujet de TP (tout au long) ====
Il se trouve que lors du déroulement du projet, on pourra être amené à se poser des questions au niveau des réglages de la chaine de transmission.
Or il est fort probable que les élèves qui travailleront sur ce TP pourront alors se poser les mêmes questions.
C'est pour cela qui sera judicieux de prendre soin de noter les problématiques rencontrées et de donner un certain fil de développement pour venir à bout de la problématique posée.
Ce qui reviendra à proposer des axes/questions sur les manipulations de cette maquette de TP.

== Note valable pour toutes les semaines ==

'''[[Si un point vous semble imprécis, veuillez vous reporter aux détails fournis en annexe.]]'''

== 1éme semaine: (du 27/01/2014 au 01/02/2014) ==

Séance du 05/02/2014 :

Pour bien comprendre les différentes choses à réaliser, on a refait les manipulations vues en TP. On a, pour cela utiliser la maquette didactique TIMS pour générer différent type de modulation:

-la modulation en 4,8,16PSK (on obtient une constellation en forme de cercle).

-La modulation en 4,8,16QAM (on obtient une constellation avec un carré, ou deux: de différentes tailles).

On a très vite dégagé la nécessité de réaliser un montage générateur de tous les mots numériques possibles.
On a donc fait un programme sur arduino qui équivaut au générateur pseudo aléatoire.
Celui-ci est directement inspiré du montage que l'on a réalisé l'année dernière en conception de circuit électronique.

Séance du 06/02/2014 :

Lors de cette séance on a exploré toutes les possibilités concernant la communication entre la maquette/carte, car cela pour avoir une influence non négligeable sur le choix de la carte F.P.G.A. et du design de la maquette.

On a donc aussi fait des recherches concernant les possibilités de communications et les blocs I.P. (Intellectual Properties) permettant de programmer un F.P.G.A.

Et enfin, on a eu une discussion avec un responsable technique pour ce qui de la C.E.M. (Compatibilité Electro-Magnétique)

== 2éme semaine: (du 03/02/2014 au 08/02/2014) ==

Réflexion sur les possibilités possibles et offertes par le sujet pour ce qui est des parties de communications entre la maquette en interne et de son environnement.

[[Fichier:P34_2013_2014_schéma_principe_carte_semaine_2.PNG|300px|thumb|center|Maquette en interne/externe.]]

N'ayant jamais utilisé d'autre carte que la Nanoboard, on s'est attelé à faire des recherches sur la manière de procéder pour programmer une carte F.P.G.A., il se trouve que chaque carte de développement à ses propres manières pour être programmé.

On a pris le soin de noter toutes les questions concernant le F.P.G.A. pour un intervenant industriel qui assura un cours la semaine prochaine.

== 3éme semaine: (du 10/02/2014 au 15/02/2014) ==

Ayant les oscillateurs commandables en tension, on a pu commencer à faire une manipulation avec les composants Mini-Circuit.

Mais après un problème suite à une manipulation l'un des VCOs ne fonctionne plus.

Ce qui nous amène à penser qu'il sera judicieux de prévoir une alimentation au niveau de la carte.

Celle-ci devra être inférieure ou égale à la tension maximale d'alimentation du composant (ceux-ci étant très sensible).

Questions/Réponses:

Comment fait-on pour programmer une carte F.P.G.A. est-ce que la programmation se fait "in situe" ? (in situe : c'est à dire sur la carte elle-même)
Oui, c'est ce qui est utilisé, via un câble JTAG.

Est-ce possible faire une interface USB pour permettre à un ordinateur de communiquer avec la maquette/carte via un F.P.G.A. ? Oui.

Est-ce que la gestion de l'interface Ethernet est envisageable ? Oui.

Pour une communication en protocole UDP avec un ordinateur via une liaison Ethernet, est-ce qu'il y a d'autres façons que d'utiliser un "SoftCore" ?

Oui, il existe aussi bien en Software, qu'en Hardware.

== 4éme semaine: (du 17/02/2014 au 22/02/2014) ==

On a donc repris l'idée de la 2éme semaine.

Après avoir mis en place un cahier des charges au niveau des qualités, bande passante minimale.

Nous avons fait des recherches sur les composants à utiliser (i.e. CAN, CAN, ...)

Ce qui nous a permis après une édition rapide de schéma électrique (schematic) d'avoir une idée du nombre de pins dont nous aurons besoin sur une carte FPGA afin de réaliser le projet.

Après prospection, il se trouve que nous nous dirigerions vers la carte Digilent Spartan 3, dont l'école était déjà en possession.

Donc nous nous sommes attelés à faire des recherches et des essais sur cette carte et pour notamment trouver un moyen de la faire fonctionner.

== 5éme semaine: (du 03/03/2014 au 08/03/2014) ==

Tout d'abord, après plusieurs heures de recherches et d'essai infructueux, on a fini par trouver les drivers pour le câble USB diligent.

Et donc ainsi avoir un fonctionnement de la communication via le câble JTAG plus propice au fonctionnement de la carte.

On a pu enfin se conforter sur une partie des composants et des dimensionnements pour certains d'entre eux (valeur de résistance,capacité...)

Schématics: Édition de multiple bibliothèque pour Altium, intégrant à la fois schématics et leur empreinte PCB associée.

(On a pu constater qu'une interface 3v3 5v n'est pas forcement nécessaire pour assurer le bon fonctionnement entre deux cartes avec des tensions d'alimentation différentes.)

== 6éme semaine: (du 10/03/2014 au 15/03/2014) ==

On a pu enfin se conforter sur l'ensemble des composants et des choix de régulateur et utilisation d'autre diode Zener.

On trouvera le schéma intégral avec les bibliothèques nécessaires dans la semaine 5.

Cette semaine a été dédiée à l'envoi de la commande des composants au sein du magasin de l'école et du fournisseur.

Après envoi de la commande, il se trouve que le projet a changé d'objectif principal.

Il est maintenant prioritaire de réaliser un code VHDL capable d'évaluer la vitesse de transmission numérique du côté récepteur.

== 7éme semaine: (du 17/03/2014 au 22/03/2014) ==

Pour cette semaine, on s'est concentré sur la réalisation d'un générateur pseudo aléatoire en interne au FPGA.

On réalisera une échelle de résistance afin de réaliser une conversion numérique analogique afin de l'envoyer sur la chaine de transmission.

Ce code de "base" nous permettra de réaliser un flux de données fictif pour obtenir toutes les combinaisons récupérant le résultat du bus.

[[MédiaP34_2013_2014_gene_pseudo_19_03_2014_6_semaine_7.zip|Archive contenant le projet ISE Xilinx.]]

[[Fichier:P34_2013_2014_rtl_semaine_7.PNG|300px|thumb|center|extrait du schéma RTL, on peut y voir clairement les inférences de Xilinx.]]

Ce schéma a deux entrées et une sortie, une entrée d'initialisation, une horloge et une sortie pour la trame en pseudo aléatoire.

On fera l'essai sur la carte lors de la semaine suivante.

== 8éme semaine: (du 24/03/2014 au 26/03/2014) ==

Après le premier test, on pourrait penser que l'on récupère du bruit en sortie de la carte:

[[Fichier:P34_2013_2014_DSC_0024_1_probleme_d_overshoot_semaine_8.jpg|300px|thumb|center|Overshoot.]]

Pour pouvoir remédier à ce problème, on a fait une prédivision de l'horloge

[[Fichier:P34_2013_2014_DSC_0037_1_div_freq_semaine_8.jpg|300px|thumb|center|Overshoot après division.]]

[[Fichier:P34_2013_2014_DSC_0039_1_div_freq_zoom_semaine_8.jpg|300px|thumb|center|Overshoot après division (Zoom).]]

Archive contenant toutes les modifications:

[[Média:P34_2013_2014_gene_pseudo_26_03_2014_2_semaine_8.zip|VHDL Semaine 8.]]

On a trouvé un moyen de faire un CNA facilement, via une "échelle dite R-2R". [[http://www.uchobby.com/index.php/2008/01/08/arduino-audio-dac-options/|Pour le réseau R 2R.]]

Il faut encore modifier le VHDL pour pouvoir l'exploiter et ainsi générer une constellation.

== 9éme semaine: (du 28/03/2014 au 03/04/2014) ==

On a pris donc le soin de modifier le VHDL:

[[Média:P34_2013_2014_gene_pseudo_31_03_2014_1_semaine_9.zip|VHDL semaine 9]]

Ce VHDL à été mis à jour, avec deux entrées (initialisation et une horloge) et un bus de sortie (8 bits), avec les trames pseudoaléatoires.

On envoie ces signaux sur deux C.N.A.s (4 bits chacun) pour générer deux signaux I et Q, on peut voir une constellation se dessiner en mode X-Y.

[[Fichier:P34_2013_2014_DSC_0072_1_Montage_entier_4qam_semaine_9.jpg|300px|thumb|center|Montage avec constellations 4QAM.]]

D'autres constellations réalisées sont disponibles en annexe. On peut monter jusqu'à une constellation de 256 points (2^4*2^4).

On a réalisé le montage complet de toute la chaine de transmission. Il se trouve que la Boucle à Verrouillage de Phase (ou appellée PLL, Phase Loop Locker) ne se verrouille pas sur la porteuse du signal que l'on souhaite récupéré, de ce fait on ne peut pas récupérer les signaux I et Q.

== 10éme semaine: (du 07/04/2014 au 10/04/2014) ==

On a réalisé le montage que l'on évoquait en semaine 9:

[[Fichier:P34_2013_2014_DSC_0027_montage_realisee_semaine_10.jpg|center|thumb|300px|Montage pour améliorer la PLL.]]

Il se trouve qu’après un réglage précis de la tension d'offset permettant d'être un proche de la fréquence à capturer on obtient:

[[Fichier:P34_2013_2014_DSC_0025_PLL_non_verrouillage_semaine_10.jpg|center|thumb|300px|Signaux I/Q après ajout du montage.]]

= Annexes =

== Annexe A: Détails techniques des semaines ==

=== 1éme semaine: (du 27/01/2014 au 01/02/2014) ===

Après on a réfléchi sur la potentielle conception/utilisation d'une carte FPGA.
Il sera judicieux de ne pas se précipiter sur le schéma et la conception/utilisation d'une carte FPGA, sans avoir, au préalable fait le VHDL et le testez avec un banc de test virtuel.
L'intérêt et de mettre en valeur la nécessité ou non de certains signaux pour le schéma de la carte.
On va mettre en oeuvre les connaissances acquises au S7 en VHDL (en TP de Circuit Numérique Programmble).

Pour ce qui est de l'Arduino, on a répondu aux interrogations suivantes (certaines de ces questions paraissent triviales, mais on préfère éviter les surprises):

Quelle est la vitesse maximale de la communication série de l'Arduino ?
-115200bauds

Est-ce que, un programme de type "Analog Write" est-il une vraie sortie analogique ?

-Non, c'est juste une PWM. Elle sera exploitable pour faire les signales I/Q mais très contraignantes, car il faudra filtré le signal, et ce sera beaucoup trop lent (du au fait que la modulation est faite au alentour de 850Mhz), le FPGA sera un passage obligé cela ouvrira les portes d'un plus grand débit.

==== Manipulation réalisée sur la maquette TIMS : ====

On a fait un des montages présentés dans l'ouvrage "Volume D1 Fundamental Digital Experiments" dans le but de visualiser l’objectif à atteindre.

On obtient la constellation suivante (16QAM):

[[Fichier:P34_2013_2014_constelation_tims_semaine_1.PNG|300px|thumb|center|Constellation visualisée en mode X-Y.]]

Ce qui correspond à deux signaux en visualisation temporelle de cette forme :

[[Fichier:P34_2013_2014_constelation_temporelle_tims_semaine_1.PNG|300px|thumb|center|Signaux I et Q. (Image très floutée, à remplacer)]]

On pourra facilement obtenir le même résultat en générant un bus de trame pseudo aléatoire et en l'injectant dans un C.N.A. (Conversion Numérique Analogique)

==== Code Arduino réalisé: ====

[[Fichier:P34_2013_2014_schema_electronique_generateur_pseudo_aleatoire.png|300px|thumb|center|Schéma électronique du générateur pseudo aléatoire.]]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_chrono_simule.PNG|300px|thumb|center|Résultat de la simulation du générateur pseudo aléatoire (on a eu la même chose en pratique).]]

[code]
/*A peut-être supprimer*/
#include <avr/io.h>
#include <util/delay.h>

void output_init(void){
DDRB |= 0x02; // PIN 8,9 sont les deux sorties.
}

int main(void){
int r1=1,r2=0,r3=0,r4=0,r5=0,retard=0;
PORTB=0x00;
while(1)
{
r5=r4;//chaque affectation représente une recopie de la bascule sur le "front montant", ici c'est simplement l’exécution du code.
r4=r3;
r3=r2;
r2=r1;
r1=r4^r5;
PORTB=0x01*r1+0x02*retard;//écriture des signaux
_delay_ms(10);//le "front montant", ce qui permet de faire un genre d'horloge.
retard=r5;//déphasage du signal
}
return 0;
}
[/code]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_arduino.jpg|300px|thumb|center|Resultat avec le générateur pseudo aléatoire "émuler" avec l'Arduino.]]

Comparaison carte réelle/résultat Arduino:

C'était exactement les signaux attendus (même s'il y un décalage a par rapport à l'original).

On aura bien pour une QPSK (4PSK) tous les couples (ie 00,01,11 et 10).

À propos de l'arduino, on pourra envisager une amélioration pour générer une séquence plus longue:

-il faudra simplement utiliser un tableau d'entier.

-paramétrer sa taille avec un N par exemple.

-N correspondra à la taille de séquence de longueur 2^N.

Voir la section "Code Arduino réalisé" en annexe B dans la semaine correspondante.

==== Possibilités de communications: ====

Exploration des possibilités de communication entre le PC et la carte en amont:

=====-> Ethernet: =====

*+ Vitesse de transmission (~10M-100M-G)bauds

*- La gestion du flux de données doit être faite par un microcontrôleur (celui-ci pourra être implémenté un bloc I.P. à l'intérieur du FPGA)

-> - Haute consommation de CLB du FPGA.

=====-> SPI (communication série): =====

*- Vitesse de transmission

-> Arduino capable de communiquer jusqu'a 115200 bauds

-> D'après certaines discussions sur des forums, on pourrait « pousser » au-delà.

=====-> I2C : =====

Communication abandonnée, ce n'est pas une priorité.

==== À propos des blocs I.P.: ====

En consultant les ordinateurs et en s'appuyant des T.P.s de CNP, on constate que les blocs suivants existent:

- Xilinx Microblaze/Xilinx Power PC ("µP FPGA")

-> Est-ce possible d'utiliser ces blocs I.P. pour programmer un FPGA sur une carte autre que la Nanoboard ? Comment ?

- EMACx (Ethernet Media Acess Control)(:lien physique entre processeurs et "standart Physical Layer device IEEE802.3")

===== Conception de la carte: =====

L'idéal est de se documenter sur la Compatibilité électromagnétique.

=== 2éme semaine: (du 03/02/2014 au 08/02/2014) ===

(Rien pour l'annexe.)

=== 3éme semaine: (du 10/02/2014 au 15/02/2014) ===

Lors de cette semaine, après avoir eu le problème de manipulation, nous avons pu prendre connaissance d'un certain montage qui s’avéra utile pour la conception de la carte/maquette.

[[Fichier:P34_2013_2014_schéma_limiteur_de_courant_semaine_3.PNG|300px|thumb|center|Schéma limiteur de courant.]]

On remarquera que ce montage se retrouve dans la partie "typical application" de la documentation technique du 7805.

=== 4éme semaine: (du 17/02/2014 au 22/02/2014) ===

On souhaite pouvoir réaliser une communication unidirectionnelle ou même transmettre un signal audio ce qui nous contraint à une bande passante minimale de 48kHz, on prendra 200kHz (pour être bien au-delà de la condition du théorème de Shannon): le but serait donc de brancher par exemple une source audio quelconque puis de la transmettre à travers la maquette et de la recomposer en fin de chaine.

Après édition rapide du schéma, on en dégage qu'il nous faudra un minimum d'environ 50 entrées/sorties. Mais ceci ce nombre sera très probablement revu à la hausse lors de prochaine séance.

Voici la carte que l'on utilisera dans la suite du projet:

[[Fichier:P34_2013_2014_S3BOARD-top-400_semaine_4.gif|300px|thumb|center|Digilent Spartan 3.]]

=== 5éme semaine: (du 03/03/2014 au 08/03/2014) ===

Lien vers le Design complet avec les librairies incluses (on remarquera qu'il serait judicieux d’installer toutes les librairies avant d’essayer d'ouvrir le schéma)

A notez aussi que l'on trouvera des reliques de feuilles Excel permettant de trouver rapidement des ratios dans la série E12.

[[Média:P34_2013_2014_Design_pcb_plus_librairies_semaine_5_6.zip|Schéma + Bibliothèques.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.pdf|Schéma en PDF.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.png|Schéma au format A2.]]

=== 6éme semaine: (du 10/03/2014 au 15/03/2014) ===

(Rien pour l'annexe.)

=== 7éme semaine: (du 17/03/2014 au 22/03/2014) ===

(Rien pour l'annexe.)

=== 8éme semaine: (du 24/03/2014 au 26/03/2014) ===

(Rien pour l'annexe.)

=== 9éme semaine: (du 28/03/2014 au 03/04/2014) ===

[[Fichier:P34_2013_2014_DSC_0061_1_r_2r_semaine_9.jpg|center|thumb|300px|Le réseau R-2R.]]

[[Fichier:P34_2013_2014_DSC_0062_1_4QAM_semaine_9.jpg|center|thumb|300px|4QAM.]]

[[Fichier:P34_2013_2014_DSC_0066_1_16QAM_semaine_9.jpg|center|thumb|300px|16QAM.]]

[[Fichier:P34_2013_2014_DSC_0069_1_64QAM_semaine_9.jpg|center|thumb|300px|64QAM.]]

Pas de photos pour la constellation à 256 points, mais elle a été réalisée.

Pour ce qui est du montage, malgré que la P.L.L., on a un signal d'erreur après filtrage :

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Chaine 1: Vtune (commande du V.C.O.)/Chaine 2: "erreur" de commande]]

Ce qui met en valeur immédiatement deux problèmes majeurs:

La chaine fonctionne sur le papier, mais lors de sa mise en pratique, il faut penser à mettre une tension d'offset et aussi réaliser une amplification de l'erreur pour avoir des grandeurs de commande adaptée au Vtune du V.C.O..

On propose l'amélioration suivante (qui sera réalisé à la prochaine séance):

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Proposition de voie d'amélioration.]]

On remarquera que les valeurs des résistances et des capacités on était choisi pour permettre un fonctionnement correct des A.O. (Amplificateur Opérationnel), mais pas pour ce qui de l'asservissement de la boucle par manque de temps.

A la fin de cette, on a eu à démonter le montage à cause de contraintes concernant les Mini-circuits (car utilisé en travaux pratiques).

=== 10éme semaine: (du 07/04/2014 au 10/04/2014) ===

Spectres des signaux de la chaine de transmission:

[[Fichier:P34_2013_2014_DSC_0001_allure_spectre_reception_semaine_10.jpg|center|thumb|300px|Spectre en réception.]]

Porteuse utilisée pour la modulation I/Q à environ 60MHz.

Porteuse utilisée pour le transport en fréquence à environ 810MHz:

[[Fichier:P34_2013_2014_DSC_0035_constellation_recupere_PLL_NV_semaine_10.jpg|center|thumb|300px|"Constellation" récupérée avec la PLL défectueuse (on souhaite se verrouiller sur la raie à 868MHz).]]

Question en suspens: faudrait'il utiliser un filtre passe-bande incluant 868Mhz pour pouvoir se verrouiller sur cette fréquence ?

On remarquera le fait que l'oscillateur du côté de la chaine d'émission a d'importantes non-linéarités (on peut observer à l'analyseur de spectre 3 à 4 raies aux fréquences multiples).

Ce qui donne un diagramme de constellation plutôt mauvais si l'on fait le montage suivant:

[[Fichier:P34_2013_2014_montage_non_linearite_vco_constellation_semaine_10.PNG|center|thumb|300px|Montage réalisée.]]

[[Fichier:P34_2013_2014_sortie_montage_non_linearite_semaine_10.PNG|center|thumb|300px|La constellation 4QAM est attendue, on est loin du résultat attendu (aucune photo n'a était réalisé d'ou le dessin).]]

== Annexe B: Digilent Spartan 3 ==

=== Procédure pour faire fonctionner la carte Digilent Spartan 3: ===

Ne connectez pas de connecteur JTAG pendant les installations. Redémarrez après chaque installation.

Tout d'abord, il faut savoir que le l'ISE Webpack 14.6 fonctionne avec la carte (n'utilisez pas la 14.7, elle ne supporte pas la génération spartan 3 !):

Installez donc l'ISE WebPack 14.6 (ou antérieur à condition que celle-ci soit supérieur à la 7.1i (d'après leur documentation))

(voir lien utile sur Xilinx)

Une fois l'installation de l'ISE terminé, faites en sorte d'avoir celui que soit opérationnel (la licence est gratuite !).

Installez la "library" ADEPT 2.3 voir le lien utile.

Après vous n'avez plus qu'a utilisez ISE Xilinx normalement et vous serez capable de reconnaitre la carte via la liaison JTAG, et de le programmer.

=== Liens utiles: ===

Lien constructeur/vendeur (avec ressources utiles en bas de la page):

http://www.digilentinc.com/Products/Detail.cfm?Prod=S3BOARD

Lien "Library" pour le câble USB digilent:

http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,66,69&Prod=ADEPT

Lien Xilinx (Pour l'ISE 14.6):

http://www.xilinx.com/products/design-tools/ise-design-suite/index.htm

Lien Xilinx (Pour les versions antérieures veuillez faire attention au système d'exploitation, votre architecture matérielle et le FPGA cible):

(Les informations de compatibilité son sur la page suivante:) (mots clés: xilinx classic(s))

http://www.xilinx.com/tools/classics.htm

=== Procédure pour faire une programmation en volatile: ===

Générer le bitstream, et le charger.

=== Procédure pour faire une programmation en "non"-volatile: ===

Générer le bitstream et l'utiliser pour générer un .mcs qui vous permettra d'inscrire le programme dans la mémoire (E?)PROM.

On remarquera que la programmation en non volatile est utile pour faire un remise à zéro et recharger le contenu de l'(E?)PROM, mais semble être sensible au débranchement de l'adaptateur d'alimentation de la carte.

=== Exemple de programmation: ===

Voir le lien digilent pour ceci dans cette annexe.

Modem pour le numérique

2014-04-13T20:58:45Z

Jvaessen : /* Annexes */

= Modulateur et démodulateur pour communications numériques =

== Cahier des charges ==

=== Présentation générale du projet ===

Dans le cadre des TPs d'électronique et de transmission RF, nous avons découvert qu'il existe plusieurs modes de modulation, pour transmettre un signal modulant.

Celles vues en TP au S7 sont la modulation en amplitude, en fréquence, en phase, en BPSK et en QPSK.

Or les modulations en phase, en fréquence et en amplitude étant celles les plus connues, la modulation en QAM (Modulation d'Amplitude en Quadrature) est quant à elle moins connue, mais tout aussi utilisées:

-pour la TNT en 64 QAM (en France).

[[Fichier:P34_2013_2014_64qam.jpg|300px|thumb|center|Exemple de constellation 64QAM.]]

-pour le WiFi en 64-QAM ou 256-QAM (à vérifier).

Or ces deux dernières étant peu représentées au niveau des travaux pratiques, ce projet permettra de fournir un peu plus de pratique sur les modulations de type QAM (en diagramme I/Q) dans le domaine des radiofréquences (~800MHz).

(Le nombre devant le QAM indique le nombre de points dans le diagramme I/Q qu'on appelle aussi constellation)

On se réserve le droit de faire '''évoluer''' le cahier des charges a posteriori, si certaines contraintes étaient amenées à évoluer ou se préciser.

=== Objectif et intérêt du projet ===

Pour cela, on nous a fourni des modules commerciaux Mini-circuit pouvant travailler dans les radios-fréquences.

Ceux-ci permettront de mettre en place une grande partie de la chaine de transmission (voir schéma de la chaine de transmission).

[[Fichier:P34_2013_2014_Chaine_modulation.PNG|300px|thumb|center|Modulation.]]

[[Fichier:P34_2013_2014_Chaine_demodulation.PNG|300px|thumb|center|Démodulation.]]

On a tout d'abord à mettre en place une carte FPGA et/ou un dispositif permettant d'envoyer un flux de données numériques continuellement pour pouvoir visualiser le diagramme I/Q (mise en valeur du diagramme I/Q et voir même un diagramme un peu plus complexe que le BPSK ou le QPSK).

Le canal de transmission qui sera un simple fil électrique, mais pourra devenir une antenne réceptrice et émettrice si le temps imparti le permet (mise en valeur du et mesure du Bit Error Rate qui sera bien sûr différent suivant le canal de transmission).

Du côté réception ,après démodulation du signal, une remise en forme et une interprétation des données seront réalisées, celle-ci dépendra bien entendu de la provenance du flux de données (constater le succès ou l'échec d'un envoi de données).

Enfin si le temps le permets on pourra mettre en une place un système de codage de l'information avec par exemple un codage redondant permettant de corrigé l'erreur (À définir, on pourra faire constater l'efficacité d'une méthode de codage au choix).

=== Étapes/Déroulement du projet ===

De même que pour le cahier des charges, il se peut que les étapes diffèrent plus ou moins, en fonction des disponibilités, matérielles et contraintes.

==== => Caractérisation des blocs Mini-circuits et épluchage des documentations techniques====
Avant de les utiliser dans la chaine de transmission, nous avons à faire une caractérisation des blocs fournis:

-la caractérisation du VCO.

-l'étude des possibilités offerte par le modulateur (cela déterminera le nombre de points possible dans la constellation, ie savoir si l'on peut aller au-delà de la QPSK).

-la caractérisation des mélangeurs (Mixer), leurs facteurs réels de multiplication.

==== => Utilisation et exploitation des caractérisations ====
On pourra ensuite trouver les paramètres pour régler correctement dans notre chaine de transmission certains de nos sous-systèmes comme la boucle à verrouillage de phase.

==== => Génération d'un flux des données numériques ====
Comme dit précédemment, l'idéal et d'avoir un flux de données numériques transmis en permanence.
Pour cela plusieurs solutions s'offre à nous, on pourra utiliser un montage générateur pseudo aléatoire (un circuit que l'on a fait l'année dernière en Conception de Circuit Électronique).
On pourra "émuler" ce montage avec un Arduino, ou bien même le faire au moyen de la Nanoboard.
On pourra aussi transmettre des chaines de caractère en continu.

==== => Test de la chaine ====
Une fois les étapes précédentes réalisées, on pourra passer au test de la chaine de transmission. Il faudra vérifier le bon fonctionnement en aval, dedans (boucle à verrouillage de phase), et en amont de la chaine de transmission.

==== => Première mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.
Il est possible que la conception d'un dispositif soit nécessaire que ce soit pour les deux mesures du B.E.R..

==== => Antennes ====
Si toutes les étapes précédentes sont satisfaites, on pourra alors faire un canal de transmission plus intéressant, à savoir l'air.
Nous passerons alors à la conception des antennes, émettrice et réceptrice.

==== => Deuxième mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.

==== => Codage de l'information et correction d'erreur ====
En toute fin de ce projet, on pourra même mettre deux dispositifs en aval et en amont de la chaine de transmission.
On réalisera alors un codeur et un décodeur permettant de faire de la détection/correction d'erreur.

==== => Mise en place d'outil de débogage (tout au long)====
La mise en place de simples outils de débogage et primordiale, ceux-ci permettront de vérifier le bon fonctionnement de la chaine.

==== => Proposition d'un sujet de TP (tout au long) ====
Il se trouve que lors du déroulement du projet, on pourra être amené à se poser des questions au niveau des réglages de la chaine de transmission.
Or il est fort probable que les élèves qui travailleront sur ce TP pourront alors se poser les mêmes questions.
C'est pour cela qui sera judicieux de prendre soin de noter les problématiques rencontrées et de donner un certain fil de développement pour venir à bout de la problématique posée.
Ce qui reviendra à proposer des axes/questions sur les manipulations de cette maquette de TP.

== Note valable pour toutes les semaines ==

'''[[Si un point vous semble imprécis, veuillez vous reporter aux détails fournis en annexe.]]'''

== 1éme semaine: (du 27/01/2014 au 01/02/2014) ==

Séance du 05/02/2014 :

Pour bien comprendre les différentes choses à réaliser, on a refait les manipulations vues en TP. On a, pour cela utiliser la maquette didactique TIMS pour générer différent type de modulation:

-la modulation en 4,8,16PSK (on obtient une constellation en forme de cercle).

-La modulation en 4,8,16QAM (on obtient une constellation avec un carré, ou deux: de différentes tailles).

On a très vite dégagé la nécessité de réaliser un montage générateur de tous les mots numériques possibles.
On a donc fait un programme sur arduino qui équivaut au générateur pseudo aléatoire.
Celui-ci est directement inspiré du montage que l'on a réalisé l'année dernière en conception de circuit électronique.

Séance du 06/02/2014 :

Lors de cette séance on a exploré toutes les possibilités concernant la communication entre la maquette/carte, car cela pour avoir une influence non négligeable sur le choix de la carte F.P.G.A. et du design de la maquette.

On a donc aussi fait des recherches concernant les possibilités de communications et les blocs I.P. (Intellectual Properties) permettant de programmer un F.P.G.A.

Et enfin, on a eu une discussion avec un responsable technique pour ce qui de la C.E.M. (Compatibilité Electro-Magnétique)

== 2éme semaine: (du 03/02/2014 au 08/02/2014) ==

Réflexion sur les possibilités possibles et offertes par le sujet pour ce qui est des parties de communications entre la maquette en interne et de son environnement.

[[Fichier:P34_2013_2014_schéma_principe_carte_semaine_2.PNG|300px|thumb|center|Maquette en interne/externe.]]

N'ayant jamais utilisé d'autre carte que la Nanoboard, on s'est attelé à faire des recherches sur la manière de procéder pour programmer une carte F.P.G.A., il se trouve que chaque carte de développement à ses propres manières pour être programmé.

On a pris le soin de noter toutes les questions concernant le F.P.G.A. pour un intervenant industriel qui assura un cours la semaine prochaine.

== 3éme semaine: (du 10/02/2014 au 15/02/2014) ==

Ayant les oscillateurs commandables en tension, on a pu commencer à faire une manipulation avec les composants Mini-Circuit.

Mais après un problème suite à une manipulation l'un des VCOs ne fonctionne plus.

Ce qui nous amène à penser qu'il sera judicieux de prévoir une alimentation au niveau de la carte.

Celle-ci devra être inférieure ou égale à la tension maximale d'alimentation du composant (ceux-ci étant très sensible).

Questions/Réponses:

Comment fait-on pour programmer une carte F.P.G.A. est-ce que la programmation se fait "in situe" ? (in situe : c'est à dire sur la carte elle-même)
Oui, c'est ce qui est utilisé, via un câble JTAG.

Est-ce possible faire une interface USB pour permettre à un ordinateur de communiquer avec la maquette/carte via un F.P.G.A. ? Oui.

Est-ce que la gestion de l'interface Ethernet est envisageable ? Oui.

Pour une communication en protocole UDP avec un ordinateur via une liaison Ethernet, est-ce qu'il y a d'autres façons que d'utiliser un "SoftCore" ?

Oui, il existe aussi bien en Software, qu'en Hardware.

== 4éme semaine: (du 17/02/2014 au 22/02/2014) ==

On a donc repris l'idée de la 2éme semaine.

Après avoir mis en place un cahier des charges au niveau des qualités, bande passante minimale.

Nous avons fait des recherches sur les composants à utiliser (i.e. CAN, CAN, ...)

Ce qui nous a permis après une édition rapide de schéma électrique (schematic) d'avoir une idée du nombre de pins dont nous aurons besoin sur une carte FPGA afin de réaliser le projet.

Après prospection, il se trouve que nous nous dirigerions vers la carte Digilent Spartan 3, dont l'école était déjà en possession.

Donc nous nous sommes attelés à faire des recherches et des essais sur cette carte et pour notamment trouver un moyen de la faire fonctionner.

== 5éme semaine: (du 03/03/2014 au 08/03/2014) ==

Tout d'abord, après plusieurs heures de recherches et d'essai infructueux, on a fini par trouver les drivers pour le câble USB diligent.

Et donc ainsi avoir un fonctionnement de la communication via le câble JTAG plus propice au fonctionnement de la carte.

On a pu enfin se conforter sur une partie des composants et des dimensionnements pour certains d'entre eux (valeur de résistance,capacité...)

Schématics: Édition de multiple bibliothèque pour Altium, intégrant à la fois schématics et leur empreinte PCB associée.

(On a pu constater qu'une interface 3v3 5v n'est pas forcement nécessaire pour assurer le bon fonctionnement entre deux cartes avec des tensions d'alimentation différentes.)

== 6éme semaine: (du 10/03/2014 au 15/03/2014) ==

On a pu enfin se conforter sur l'ensemble des composants et des choix de régulateur et utilisation d'autre diode Zener.

On trouvera le schéma intégral avec les bibliothèques nécessaires dans la semaine 5.

Cette semaine a été dédiée à l'envoi de la commande des composants au sein du magasin de l'école et du fournisseur.

Après envoi de la commande, il se trouve que le projet a changé d'objectif principal.

Il est maintenant prioritaire de réaliser un code VHDL capable d'évaluer la vitesse de transmission numérique du côté récepteur.

== 7éme semaine: (du 17/03/2014 au 22/03/2014) ==

Pour cette semaine, on s'est concentré sur la réalisation d'un générateur pseudo aléatoire en interne au FPGA.

On réalisera une échelle de résistance afin de réaliser une conversion numérique analogique afin de l'envoyer sur la chaine de transmission.

Ce code de "base" nous permettra de réaliser un flux de données fictif pour obtenir toutes les combinaisons récupérant le résultat du bus.

[[MédiaP34_2013_2014_gene_pseudo_19_03_2014_6_semaine_7.zip|Archive contenant le projet ISE Xilinx.]]

[[Fichier:P34_2013_2014_rtl_semaine_7.PNG|300px|thumb|center|extrait du schéma RTL, on peut y voir clairement les inférences de Xilinx.]]

Ce schéma a deux entrées et une sortie, une entrée d'initialisation, une horloge et une sortie pour la trame en pseudo aléatoire.

On fera l'essai sur la carte lors de la semaine suivante.

== 8éme semaine: (du 24/03/2014 au 26/03/2014) ==

Après le premier test, on pourrait penser que l'on récupère du bruit en sortie de la carte:

[[Fichier:P34_2013_2014_DSC_0024_1_probleme_d_overshoot_semaine_8.jpg|300px|thumb|center|Overshoot.]]

Pour pouvoir remédier à ce problème, on a fait une prédivision de l'horloge

[[Fichier:P34_2013_2014_DSC_0037_1_div_freq_semaine_8.jpg|300px|thumb|center|Overshoot après division.]]

[[Fichier:P34_2013_2014_DSC_0039_1_div_freq_zoom_semaine_8.jpg|300px|thumb|center|Overshoot après division (Zoom).]]

Archive contenant toutes les modifications:

[[Média:P34_2013_2014_gene_pseudo_26_03_2014_2_semaine_8.zip|VHDL Semaine 8.]]

On a trouvé un moyen de faire un CNA facilement, via une "échelle dite R-2R". [[http://www.uchobby.com/index.php/2008/01/08/arduino-audio-dac-options/|Pour le réseau R 2R.]]

Il faut encore modifier le VHDL pour pouvoir l'exploiter et ainsi générer une constellation.

== 9éme semaine: (du 28/03/2014 au 03/04/2014) ==

On a pris donc le soin de modifier le VHDL:

[[Média:P34_2013_2014_gene_pseudo_31_03_2014_1_semaine_9.zip|VHDL semaine 9]]

Ce VHDL à été mis à jour, avec deux entrées (initialisation et une horloge) et un bus de sortie (8 bits), avec les trames pseudoaléatoires.

On envoie ces signaux sur deux C.N.A.s (4 bits chacun) pour générer deux signaux I et Q, on peut voir une constellation se dessiner en mode X-Y.

[[Fichier:P34_2013_2014_DSC_0072_1_Montage_entier_4qam_semaine_9.jpg|300px|thumb|center|Montage avec constellations 4QAM.]]

D'autres constellations réalisées sont disponibles en annexe. On peut monter jusqu'à une constellation de 256 points (2^4*2^4).

On a réalisé le montage complet de toute la chaine de transmission. Il se trouve que la Boucle à Verrouillage de Phase (ou appellée PLL, Phase Loop Locker) ne se verrouille pas sur la porteuse du signal que l'on souhaite récupéré, de ce fait on ne peut pas récupérer les signaux I et Q.

== 10éme semaine: (du 07/04/2014 au 10/04/2014) ==

On a réalisé le montage que l'on évoquait en semaine 9:

[[Fichier:P34_2013_2014_DSC_0027_montage_realisee_semaine_10.jpg|center|thumb|300px|Montage pour améliorer la PLL.]]

Il se trouve qu’après un réglage précis de la tension d'offset permettant d'être un proche de la fréquence à capturer on obtient:

[[Fichier:P34_2013_2014_DSC_0025_PLL_non_verrouillage_semaine_10.jpg|center|thumb|300px|Signaux I/Q après ajout du montage.]]

= Annexes =

== Annexe A: Détails techniques des semaines ==

=== 1éme semaine: (du 27/01/2014 au 01/02/2014) ===

Après on a réfléchi sur la potentielle conception/utilisation d'une carte FPGA.
Il sera judicieux de ne pas se précipiter sur le schéma et la conception/utilisation d'une carte FPGA, sans avoir, au préalable fait le VHDL et le testez avec un banc de test virtuel.
L'intérêt et de mettre en valeur la nécessité ou non de certains signaux pour le schéma de la carte.
On va mettre en oeuvre les connaissances acquises au S7 en VHDL (en TP de Circuit Numérique Programmble).

Pour ce qui est de l'Arduino, on a répondu aux interrogations suivantes (certaines de ces questions paraissent triviales, mais on préfère éviter les surprises):

Quelle est la vitesse maximale de la communication série de l'Arduino ?
-115200bauds

Est-ce que, un programme de type "Analog Write" est-il une vraie sortie analogique ?

-Non, c'est juste une PWM. Elle sera exploitable pour faire les signales I/Q mais très contraignantes, car il faudra filtré le signal, et ce sera beaucoup trop lent (du au fait que la modulation est faite au alentour de 850Mhz), le FPGA sera un passage obligé cela ouvrira les portes d'un plus grand débit.

==== Manipulation réalisée sur la maquette TIMS : ====

On a fait un des montages présentés dans l'ouvrage "Volume D1 Fundamental Digital Experiments" dans le but de visualiser l’objectif à atteindre.

On obtient la constellation suivante (16QAM):

[[Fichier:P34_2013_2014_constelation_tims_semaine_1.PNG|300px|thumb|center|Constellation visualisée en mode X-Y.]]

Ce qui correspond à deux signaux en visualisation temporelle de cette forme :

[[Fichier:P34_2013_2014_constelation_temporelle_tims_semaine_1.PNG|300px|thumb|center|Signaux I et Q. (Image très floutée, à remplacer)]]

On pourra facilement obtenir le même résultat en générant un bus de trame pseudo aléatoire et en l'injectant dans un C.N.A. (Conversion Numérique Analogique)

==== Code Arduino réalisé: ====

[[Fichier:P34_2013_2014_schema_electronique_generateur_pseudo_aleatoire.png|300px|thumb|center|Schéma électronique du générateur pseudo aléatoire.]]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_chrono_simule.PNG|300px|thumb|center|Résultat de la simulation du générateur pseudo aléatoire (on a eu la même chose en pratique).]]

[code]
/*A peut-être supprimer*/
#include <avr/io.h>
#include <util/delay.h>

void output_init(void){
DDRB |= 0x02; // PIN 8,9 sont les deux sorties.
}

int main(void){
int r1=1,r2=0,r3=0,r4=0,r5=0,retard=0;
PORTB=0x00;
while(1)
{
r5=r4;//chaque affectation représente une recopie de la bascule sur le "front montant", ici c'est simplement l’exécution du code.
r4=r3;
r3=r2;
r2=r1;
r1=r4^r5;
PORTB=0x01*r1+0x02*retard;//écriture des signaux
_delay_ms(10);//le "front montant", ce qui permet de faire un genre d'horloge.
retard=r5;//déphasage du signal
}
return 0;
}
[/code]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_arduino.jpg|300px|thumb|center|Resultat avec le générateur pseudo aléatoire "émuler" avec l'Arduino.]]

Comparaison carte réelle/résultat Arduino:

C'était exactement les signaux attendus (même s'il y un décalage a par rapport à l'original).

On aura bien pour une QPSK (4PSK) tous les couples (ie 00,01,11 et 10).

À propos de l'arduino, on pourra envisager une amélioration pour générer une séquence plus longue:

-il faudra simplement utiliser un tableau d'entier.

-paramétrer sa taille avec un N par exemple.

-N correspondra à la taille de séquence de longueur 2^N.

Voir la section "Code Arduino réalisé" en annexe B dans la semaine correspondante.

==== Possibilités de communications: ====

Exploration des possibilités de communication entre le PC et la carte en amont:

=====-> Ethernet: =====

*+ Vitesse de transmission (~10M-100M-G)bauds

*- La gestion du flux de données doit être faite par un microcontrôleur (celui-ci pourra être implémenté un bloc I.P. à l'intérieur du FPGA)

-> - Haute consommation de CLB du FPGA.

=====-> SPI (communication série): =====

*- Vitesse de transmission

-> Arduino capable de communiquer jusqu'a 115200 bauds

-> D'après certaines discussions sur des forums, on pourrait « pousser » au-delà.

=====-> I2C : =====

Communication abandonnée, ce n'est pas une priorité.

==== À propos des blocs I.P.: ====

En consultant les ordinateurs et en s'appuyant des T.P.s de CNP, on constate que les blocs suivants existent:

- Xilinx Microblaze/Xilinx Power PC ("µP FPGA")

-> Est-ce possible d'utiliser ces blocs I.P. pour programmer un FPGA sur une carte autre que la Nanoboard ? Comment ?

- EMACx (Ethernet Media Acess Control)(:lien physique entre processeurs et "standart Physical Layer device IEEE802.3")

===== Conception de la carte: =====

L'idéal est de se documenter sur la Compatibilité électromagnétique.

=== 2éme semaine: (du 03/02/2014 au 08/02/2014) ===

(Rien pour l'annexe.)

=== 3éme semaine: (du 10/02/2014 au 15/02/2014) ===

Lors de cette semaine, après avoir eu le problème de manipulation, nous avons pu prendre connaissance d'un certain montage qui s’avéra utile pour la conception de la carte/maquette.

[[Fichier:P34_2013_2014_schéma_limiteur_de_courant_semaine_3.PNG|300px|thumb|center|Schéma limiteur de courant.]]

On remarquera que ce montage se retrouve dans la partie "typical application" de la documentation technique du 7805.

=== 4éme semaine: (du 17/02/2014 au 22/02/2014) ===

On souhaite pouvoir réaliser une communication unidirectionnelle ou même transmettre un signal audio ce qui nous contraint à une bande passante minimale de 48kHz, on prendra 200kHz (pour être bien au-delà de la condition du théorème de Shannon): le but serait donc de brancher par exemple une source audio quelconque puis de la transmettre à travers la maquette et de la recomposer en fin de chaine.

Après édition rapide du schéma, on en dégage qu'il nous faudra un minimum d'environ 50 entrées/sorties. Mais ceci ce nombre sera très probablement revu à la hausse lors de prochaine séance.

Voici la carte que l'on utilisera dans la suite du projet:

[[Fichier:P34_2013_2014_S3BOARD-top-400_semaine_4.gif|300px|thumb|center|Digilent Spartan 3.]]

=== 5éme semaine: (du 03/03/2014 au 08/03/2014) ===

Lien vers le Design complet avec les librairies incluses (on remarquera qu'il serait judicieux d’installer toutes les librairies avant d’essayer d'ouvrir le schéma)

A notez aussi que l'on trouvera des reliques de feuilles Excel permettant de trouver rapidement des ratios dans la série E12.

[[Média:P34_2013_2014_Design_pcb_plus_librairies_semaine_5_6.zip|Schéma + Bibliothèques.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.pdf|Schéma en PDF.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.png|Schéma au format A2.]]

=== 6éme semaine: (du 10/03/2014 au 15/03/2014) ===

(Rien pour l'annexe.)

=== 7éme semaine: (du 17/03/2014 au 22/03/2014) ===

(Rien pour l'annexe.)

=== 8éme semaine: (du 24/03/2014 au 26/03/2014) ===

(Rien pour l'annexe.)

=== 9éme semaine: (du 28/03/2014 au 03/04/2014) ===

[[Fichier:P34_2013_2014_DSC_0061_1_r_2r_semaine_9.jpg|center|thumb|300px|Le réseau R-2R.]]

[[Fichier:P34_2013_2014_DSC_0062_1_4QAM_semaine_9.jpg|center|thumb|300px|4QAM.]]

[[Fichier:P34_2013_2014_DSC_0066_1_16QAM_semaine_9.jpg|center|thumb|300px|16QAM.]]

[[Fichier:P34_2013_2014_DSC_0069_1_64QAM_semaine_9.jpg|center|thumb|300px|64QAM.]]

Pas de photos pour la constellation à 256 points, mais elle a été réalisée.

Pour ce qui est du montage, malgré que la P.L.L., on a un signal d'erreur après filtrage :

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Chaine 1: Vtune (commande du V.C.O.)/Chaine 2: "erreur" de commande]]

Ce qui met en valeur immédiatement deux problèmes majeurs:

La chaine fonctionne sur le papier, mais lors de sa mise en pratique, il faut penser à mettre une tension d'offset et aussi réaliser une amplification de l'erreur pour avoir des grandeurs de commande adaptée au Vtune du V.C.O..

On propose l'amélioration suivante (qui sera réalisé à la prochaine séance):

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Proposition de voie d'amélioration.]]

On remarquera que les valeurs des résistances et des capacités on était choisi pour permettre un fonctionnement correct des A.O. (Amplificateur Opérationnel), mais pas pour ce qui de l'asservissement de la boucle par manque de temps.

A la fin de cette, on a eu à démonter le montage à cause de contraintes concernant les Mini-circuits (car utilisé en travaux pratiques).

=== 10éme semaine: (du 07/04/2014 au 10/04/2014) ===

Spectres des signaux de la chaine de transmission:

[[Fichier:P34_2013_2014_DSC_0001_allure_spectre_reception_semaine_10.jpg|center|thumb|300px|Spectre en réception.]]

Porteuse utilisée pour la modulation I/Q à environ 60MHz.

P34_2013_2014_DSC_0001_allure_spectre_reception_semaine_10.jpg

Porteuse utilisée pour le transport en fréquence à environ 810MHz:

[[Fichier:P34_2013_2014_DSC_0035_constellation_recupere_PLL_NV_semaine_10.jpg|center|thumb|300px|"Constellation" récupérée avec la PLL défectueuse (on souhaite se verrouiller sur la raie à 868MHz).]]

Question en suspens: faudrait'il utiliser un filtre passe-bande incluant 868Mhz pour pouvoir se verrouiller sur cette fréquence ?

On remarquera sur le fait que l'oscillateur du côté de la chaine d'émission à d'importantes non-linéarités (on peut observer à l'analyseur de spectre 3 à 4 raies aux fréquences multiples).

Ce qui donne un diagramme de constellation plutôt mauvais si l'on fait le montage suivant:

[[Fichier:P34_2013_2014_montage_non_linearite_vco_constellation_semaine_10.PNG|center|thumb|300px|Montage réalisée.]]

[[Fichier:P34_2013_2014_sortie_montage_non_linearite_semaine_10.PNG|center|thumb|300px|La constellation 4QAM est attendue, on est loin du résultat attendu (aucune photo n'a était réalisé d'ou le dessin).]]

== Annexe B: Digilent Spartan 3 ==

=== Procédure pour faire fonctionner la carte Digilent Spartan 3: ===

Ne connectez pas de connecteur JTAG pendant les installations. Redémarrez après chaque installation.

Tout d'abord, il faut savoir que le l'ISE Webpack 14.6 fonctionne avec la carte (n'utilisez pas la 14.7, elle ne supporte pas la génération spartan 3 !):

Installez donc l'ISE WebPack 14.6 (ou antérieur à condition que celle-ci soit supérieur à la 7.1i (d'après leur documentation))

(voir lien utile sur Xilinx)

Une fois l'installation de l'ISE terminé, faites en sorte d'avoir celui que soit opérationnel (la licence est gratuite !).

Installez la "library" ADEPT 2.3 voir le lien utile.

Après vous n'avez plus qu'a utilisez ISE Xilinx normalement et vous serez capable de reconnaitre la carte via la liaison JTAG, et de le programmer.

=== Liens utiles: ===

Lien constructeur/vendeur (avec ressources utiles en bas de la page):

http://www.digilentinc.com/Products/Detail.cfm?Prod=S3BOARD

Lien "Library" pour le câble USB digilent:

http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,66,69&Prod=ADEPT

Lien Xilinx (Pour l'ISE 14.6):

http://www.xilinx.com/products/design-tools/ise-design-suite/index.htm

Lien Xilinx (Pour les versions antérieures veuillez faire attention au système d'exploitation, votre architecture matérielle et le FPGA cible):

(Les informations de compatibilité son sur la page suivante:) (mots clés: xilinx classic(s))

http://www.xilinx.com/tools/classics.htm

=== Procédure pour faire une programmation en volatile: ===

Générer le bitstream, et le charger.

=== Procédure pour faire une programmation en "non"-volatile: ===

Générer le bitstream et l'utiliser pour générer un .mcs qui vous permettra d'inscrire le programme dans la mémoire (E?)PROM.

On remarquera que la programmation en non volatile est utile pour faire un remise à zéro et recharger le contenu de l'(E?)PROM, mais semble être sensible au débranchement de l'adaptateur d'alimentation de la carte.

=== Exemple de programmation: ===

Voir le lien digilent pour ceci dans cette annexe.

Modem pour le numérique

2014-04-13T20:54:41Z

Jvaessen : /* 10éme semaine: (du 07/04/2014 au 10/04/2014) */

= Modulateur et démodulateur pour communications numériques =

== Cahier des charges ==

=== Présentation générale du projet ===

Dans le cadre des TPs d'électronique et de transmission RF, nous avons découvert qu'il existe plusieurs modes de modulation, pour transmettre un signal modulant.

Celles vues en TP au S7 sont la modulation en amplitude, en fréquence, en phase, en BPSK et en QPSK.

Or les modulations en phase, en fréquence et en amplitude étant celles les plus connues, la modulation en QAM (Modulation d'Amplitude en Quadrature) est quant à elle moins connue, mais tout aussi utilisées:

-pour la TNT en 64 QAM (en France).

[[Fichier:P34_2013_2014_64qam.jpg|300px|thumb|center|Exemple de constellation 64QAM.]]

-pour le WiFi en 64-QAM ou 256-QAM (à vérifier).

Or ces deux dernières étant peu représentées au niveau des travaux pratiques, ce projet permettra de fournir un peu plus de pratique sur les modulations de type QAM (en diagramme I/Q) dans le domaine des radiofréquences (~800MHz).

(Le nombre devant le QAM indique le nombre de points dans le diagramme I/Q qu'on appelle aussi constellation)

On se réserve le droit de faire '''évoluer''' le cahier des charges a posteriori, si certaines contraintes étaient amenées à évoluer ou se préciser.

=== Objectif et intérêt du projet ===

Pour cela, on nous a fourni des modules commerciaux Mini-circuit pouvant travailler dans les radios-fréquences.

Ceux-ci permettront de mettre en place une grande partie de la chaine de transmission (voir schéma de la chaine de transmission).

[[Fichier:P34_2013_2014_Chaine_modulation.PNG|300px|thumb|center|Modulation.]]

[[Fichier:P34_2013_2014_Chaine_demodulation.PNG|300px|thumb|center|Démodulation.]]

On a tout d'abord à mettre en place une carte FPGA et/ou un dispositif permettant d'envoyer un flux de données numériques continuellement pour pouvoir visualiser le diagramme I/Q (mise en valeur du diagramme I/Q et voir même un diagramme un peu plus complexe que le BPSK ou le QPSK).

Le canal de transmission qui sera un simple fil électrique, mais pourra devenir une antenne réceptrice et émettrice si le temps imparti le permet (mise en valeur du et mesure du Bit Error Rate qui sera bien sûr différent suivant le canal de transmission).

Du côté réception ,après démodulation du signal, une remise en forme et une interprétation des données seront réalisées, celle-ci dépendra bien entendu de la provenance du flux de données (constater le succès ou l'échec d'un envoi de données).

Enfin si le temps le permets on pourra mettre en une place un système de codage de l'information avec par exemple un codage redondant permettant de corrigé l'erreur (À définir, on pourra faire constater l'efficacité d'une méthode de codage au choix).

=== Étapes/Déroulement du projet ===

De même que pour le cahier des charges, il se peut que les étapes diffèrent plus ou moins, en fonction des disponibilités, matérielles et contraintes.

==== => Caractérisation des blocs Mini-circuits et épluchage des documentations techniques====
Avant de les utiliser dans la chaine de transmission, nous avons à faire une caractérisation des blocs fournis:

-la caractérisation du VCO.

-l'étude des possibilités offerte par le modulateur (cela déterminera le nombre de points possible dans la constellation, ie savoir si l'on peut aller au-delà de la QPSK).

-la caractérisation des mélangeurs (Mixer), leurs facteurs réels de multiplication.

==== => Utilisation et exploitation des caractérisations ====
On pourra ensuite trouver les paramètres pour régler correctement dans notre chaine de transmission certains de nos sous-systèmes comme la boucle à verrouillage de phase.

==== => Génération d'un flux des données numériques ====
Comme dit précédemment, l'idéal et d'avoir un flux de données numériques transmis en permanence.
Pour cela plusieurs solutions s'offre à nous, on pourra utiliser un montage générateur pseudo aléatoire (un circuit que l'on a fait l'année dernière en Conception de Circuit Électronique).
On pourra "émuler" ce montage avec un Arduino, ou bien même le faire au moyen de la Nanoboard.
On pourra aussi transmettre des chaines de caractère en continu.

==== => Test de la chaine ====
Une fois les étapes précédentes réalisées, on pourra passer au test de la chaine de transmission. Il faudra vérifier le bon fonctionnement en aval, dedans (boucle à verrouillage de phase), et en amont de la chaine de transmission.

==== => Première mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.
Il est possible que la conception d'un dispositif soit nécessaire que ce soit pour les deux mesures du B.E.R..

==== => Antennes ====
Si toutes les étapes précédentes sont satisfaites, on pourra alors faire un canal de transmission plus intéressant, à savoir l'air.
Nous passerons alors à la conception des antennes, émettrice et réceptrice.

==== => Deuxième mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.

==== => Codage de l'information et correction d'erreur ====
En toute fin de ce projet, on pourra même mettre deux dispositifs en aval et en amont de la chaine de transmission.
On réalisera alors un codeur et un décodeur permettant de faire de la détection/correction d'erreur.

==== => Mise en place d'outil de débogage (tout au long)====
La mise en place de simples outils de débogage et primordiale, ceux-ci permettront de vérifier le bon fonctionnement de la chaine.

==== => Proposition d'un sujet de TP (tout au long) ====
Il se trouve que lors du déroulement du projet, on pourra être amené à se poser des questions au niveau des réglages de la chaine de transmission.
Or il est fort probable que les élèves qui travailleront sur ce TP pourront alors se poser les mêmes questions.
C'est pour cela qui sera judicieux de prendre soin de noter les problématiques rencontrées et de donner un certain fil de développement pour venir à bout de la problématique posée.
Ce qui reviendra à proposer des axes/questions sur les manipulations de cette maquette de TP.

== Note valable pour toutes les semaines ==

'''[[Si un point vous semble imprécis, veuillez vous reporter aux détails fournis en annexe.]]'''

== 1éme semaine: (du 27/01/2014 au 01/02/2014) ==

Séance du 05/02/2014 :

Pour bien comprendre les différentes choses à réaliser, on a refait les manipulations vues en TP. On a, pour cela utiliser la maquette didactique TIMS pour générer différent type de modulation:

-la modulation en 4,8,16PSK (on obtient une constellation en forme de cercle).

-La modulation en 4,8,16QAM (on obtient une constellation avec un carré, ou deux: de différentes tailles).

On a très vite dégagé la nécessité de réaliser un montage générateur de tous les mots numériques possibles.
On a donc fait un programme sur arduino qui équivaut au générateur pseudo aléatoire.
Celui-ci est directement inspiré du montage que l'on a réalisé l'année dernière en conception de circuit électronique.

Séance du 06/02/2014 :

Lors de cette séance on a exploré toutes les possibilités concernant la communication entre la maquette/carte, car cela pour avoir une influence non négligeable sur le choix de la carte F.P.G.A. et du design de la maquette.

On a donc aussi fait des recherches concernant les possibilités de communications et les blocs I.P. (Intellectual Properties) permettant de programmer un F.P.G.A.

Et enfin, on a eu une discussion avec un responsable technique pour ce qui de la C.E.M. (Compatibilité Electro-Magnétique)

== 2éme semaine: (du 03/02/2014 au 08/02/2014) ==

Réflexion sur les possibilités possibles et offertes par le sujet pour ce qui est des parties de communications entre la maquette en interne et de son environnement.

[[Fichier:P34_2013_2014_schéma_principe_carte_semaine_2.PNG|300px|thumb|center|Maquette en interne/externe.]]

N'ayant jamais utilisé d'autre carte que la Nanoboard, on s'est attelé à faire des recherches sur la manière de procéder pour programmer une carte F.P.G.A., il se trouve que chaque carte de développement à ses propres manières pour être programmé.

On a pris le soin de noter toutes les questions concernant le F.P.G.A. pour un intervenant industriel qui assura un cours la semaine prochaine.

== 3éme semaine: (du 10/02/2014 au 15/02/2014) ==

Ayant les oscillateurs commandables en tension, on a pu commencer à faire une manipulation avec les composants Mini-Circuit.

Mais après un problème suite à une manipulation l'un des VCOs ne fonctionne plus.

Ce qui nous amène à penser qu'il sera judicieux de prévoir une alimentation au niveau de la carte.

Celle-ci devra être inférieure ou égale à la tension maximale d'alimentation du composant (ceux-ci étant très sensible).

Questions/Réponses:

Comment fait-on pour programmer une carte F.P.G.A. est-ce que la programmation se fait "in situe" ? (in situe : c'est à dire sur la carte elle-même)
Oui, c'est ce qui est utilisé, via un câble JTAG.

Est-ce possible faire une interface USB pour permettre à un ordinateur de communiquer avec la maquette/carte via un F.P.G.A. ? Oui.

Est-ce que la gestion de l'interface Ethernet est envisageable ? Oui.

Pour une communication en protocole UDP avec un ordinateur via une liaison Ethernet, est-ce qu'il y a d'autres façons que d'utiliser un "SoftCore" ?

Oui, il existe aussi bien en Software, qu'en Hardware.

== 4éme semaine: (du 17/02/2014 au 22/02/2014) ==

On a donc repris l'idée de la 2éme semaine.

Après avoir mis en place un cahier des charges au niveau des qualités, bande passante minimale.

Nous avons fait des recherches sur les composants à utiliser (i.e. CAN, CAN, ...)

Ce qui nous a permis après une édition rapide de schéma électrique (schematic) d'avoir une idée du nombre de pins dont nous aurons besoin sur une carte FPGA afin de réaliser le projet.

Après prospection, il se trouve que nous nous dirigerions vers la carte Digilent Spartan 3, dont l'école était déjà en possession.

Donc nous nous sommes attelés à faire des recherches et des essais sur cette carte et pour notamment trouver un moyen de la faire fonctionner.

== 5éme semaine: (du 03/03/2014 au 08/03/2014) ==

Tout d'abord, après plusieurs heures de recherches et d'essai infructueux, on a fini par trouver les drivers pour le câble USB diligent.

Et donc ainsi avoir un fonctionnement de la communication via le câble JTAG plus propice au fonctionnement de la carte.

On a pu enfin se conforter sur une partie des composants et des dimensionnements pour certains d'entre eux (valeur de résistance,capacité...)

Schématics: Édition de multiple bibliothèque pour Altium, intégrant à la fois schématics et leur empreinte PCB associée.

(On a pu constater qu'une interface 3v3 5v n'est pas forcement nécessaire pour assurer le bon fonctionnement entre deux cartes avec des tensions d'alimentation différentes.)

== 6éme semaine: (du 10/03/2014 au 15/03/2014) ==

On a pu enfin se conforter sur l'ensemble des composants et des choix de régulateur et utilisation d'autre diode Zener.

On trouvera le schéma intégral avec les bibliothèques nécessaires dans la semaine 5.

Cette semaine a été dédiée à l'envoi de la commande des composants au sein du magasin de l'école et du fournisseur.

Après envoi de la commande, il se trouve que le projet a changé d'objectif principal.

Il est maintenant prioritaire de réaliser un code VHDL capable d'évaluer la vitesse de transmission numérique du côté récepteur.

== 7éme semaine: (du 17/03/2014 au 22/03/2014) ==

Pour cette semaine, on s'est concentré sur la réalisation d'un générateur pseudo aléatoire en interne au FPGA.

On réalisera une échelle de résistance afin de réaliser une conversion numérique analogique afin de l'envoyer sur la chaine de transmission.

Ce code de "base" nous permettra de réaliser un flux de données fictif pour obtenir toutes les combinaisons récupérant le résultat du bus.

[[MédiaP34_2013_2014_gene_pseudo_19_03_2014_6_semaine_7.zip|Archive contenant le projet ISE Xilinx.]]

[[Fichier:P34_2013_2014_rtl_semaine_7.PNG|300px|thumb|center|extrait du schéma RTL, on peut y voir clairement les inférences de Xilinx.]]

Ce schéma a deux entrées et une sortie, une entrée d'initialisation, une horloge et une sortie pour la trame en pseudo aléatoire.

On fera l'essai sur la carte lors de la semaine suivante.

== 8éme semaine: (du 24/03/2014 au 26/03/2014) ==

Après le premier test, on pourrait penser que l'on récupère du bruit en sortie de la carte:

[[Fichier:P34_2013_2014_DSC_0024_1_probleme_d_overshoot_semaine_8.jpg|300px|thumb|center|Overshoot.]]

Pour pouvoir remédier à ce problème, on a fait une prédivision de l'horloge

[[Fichier:P34_2013_2014_DSC_0037_1_div_freq_semaine_8.jpg|300px|thumb|center|Overshoot après division.]]

[[Fichier:P34_2013_2014_DSC_0039_1_div_freq_zoom_semaine_8.jpg|300px|thumb|center|Overshoot après division (Zoom).]]

Archive contenant toutes les modifications:

[[Média:P34_2013_2014_gene_pseudo_26_03_2014_2_semaine_8.zip|VHDL Semaine 8.]]

On a trouvé un moyen de faire un CNA facilement, via une "échelle dite R-2R". [[http://www.uchobby.com/index.php/2008/01/08/arduino-audio-dac-options/|Pour le réseau R 2R.]]

Il faut encore modifier le VHDL pour pouvoir l'exploiter et ainsi générer une constellation.

== 9éme semaine: (du 28/03/2014 au 03/04/2014) ==

On a pris donc le soin de modifier le VHDL:

[[Média:P34_2013_2014_gene_pseudo_31_03_2014_1_semaine_9.zip|VHDL semaine 9]]

Ce VHDL à été mis à jour, avec deux entrées (initialisation et une horloge) et un bus de sortie (8 bits), avec les trames pseudoaléatoires.

On envoie ces signaux sur deux C.N.A.s (4 bits chacun) pour générer deux signaux I et Q, on peut voir une constellation se dessiner en mode X-Y.

[[Fichier:P34_2013_2014_DSC_0072_1_Montage_entier_4qam_semaine_9.jpg|300px|thumb|center|Montage avec constellations 4QAM.]]

D'autres constellations réalisées sont disponibles en annexe. On peut monter jusqu'à une constellation de 256 points (2^4*2^4).

On a réalisé le montage complet de toute la chaine de transmission. Il se trouve que la Boucle à Verrouillage de Phase (ou appellée PLL, Phase Loop Locker) ne se verrouille pas sur la porteuse du signal que l'on souhaite récupéré, de ce fait on ne peut pas récupérer les signaux I et Q.

== 10éme semaine: (du 07/04/2014 au 10/04/2014) ==

On a réalisé le montage que l'on évoquait en semaine 9:

[[Fichier:P34_2013_2014_DSC_0027_montage_realisee_semaine_10.jpg|center|thumb|300px|Montage pour améliorer la PLL.]]

Il se trouve qu’après un réglage précis de la tension d'offset permettant d'être un proche de la fréquence à capturer on obtient:

[[Fichier:P34_2013_2014_DSC_0025_PLL_non_verrouillage_semaine_10.jpg|center|thumb|300px|Signaux I/Q après ajout du montage.]]

= Annexes =

== Annexe A: Détails techniques des semaines ==

=== 1éme semaine: (du 27/01/2014 au 01/02/2014) ===

Après on a réfléchi sur la potentielle conception/utilisation d'une carte FPGA.
Il sera judicieux de ne pas se précipiter sur le schéma et la conception/utilisation d'une carte FPGA, sans avoir, au préalable fait le VHDL et le testez avec un banc de test virtuel.
L'intérêt et de mettre en valeur la nécessité ou non de certains signaux pour le schéma de la carte.
On va mettre en oeuvre les connaissances acquises au S7 en VHDL (en TP de Circuit Numérique Programmble).

Pour ce qui est de l'Arduino, on a répondu aux interrogations suivantes (certaines de ces questions paraissent triviales, mais on préfère éviter les surprises):

Quelle est la vitesse maximale de la communication série de l'Arduino ?
-115200bauds

Est-ce que, un programme de type "Analog Write" est-il une vraie sortie analogique ?

-Non, c'est juste une PWM. Elle sera exploitable pour faire les signales I/Q mais très contraignantes, car il faudra filtré le signal, et ce sera beaucoup trop lent (du au fait que la modulation est faite au alentour de 850Mhz), le FPGA sera un passage obligé cela ouvrira les portes d'un plus grand débit.

==== Manipulation réalisée sur la maquette TIMS : ====

On a fait un des montages présenté dans l'ouvrage "Volume D1 Fundamental Digital Experiments" dans le but de visualiser l’objectif à atteindre.

On obtient la constellation suivante (16QAM):

[[Fichier:P34_2013_2014_constelation_tims_semaine_1.PNG|300px|thumb|center|Constellation visualisé en mode X-Y.]]

Ce qui correspond à deux signaux en visualisation temporelle de cette forme :

[[Fichier:P34_2013_2014_constelation_temporelle_tims_semaine_1.PNG|300px|thumb|center|Signaux I et Q. (Image très flouté, à remplacer)]]

On pourra facilement obtenir le même résultat en générant un bus de trame pseudo aléatoire et en l'injectant dans un C.N.A. (Conversion Numérique Analogique)

==== Code Arduino réalisé: ====

[[Fichier:P34_2013_2014_schema_electronique_generateur_pseudo_aleatoire.png|300px|thumb|center|Schéma électronique du générateur pseudo aléatoire.]]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_chrono_simule.PNG|300px|thumb|center|Résultat de la simulation du générateur pseudo aléatoire (on a eu la même chose en pratique).]]

[code]
/*A peut être supprimer*/
#include <avr/io.h>
#include <util/delay.h>

void output_init(void){
DDRB |= 0x02; // PIN 8,9 sont les deux sorties.
}

int main(void){
int r1=1,r2=0,r3=0,r4=0,r5=0,retard=0;
PORTB=0x00;
while(1)
{
r5=r4;//chaque affectation représente une recopie de la bascule sur le "front montant", ici c'est simplement l’exécution du code.
r4=r3;
r3=r2;
r2=r1;
r1=r4^r5;
PORTB=0x01*r1+0x02*retard;//écriture des signaux
_delay_ms(10);//le "front montant", ce qui permet de faire un genre d'horloge.
retard=r5;//déphasage du signal
}
return 0;
}
[/code]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_arduino.jpg|300px|thumb|center|Resultat avec le generateur pseudo aléatoire "émuler" avec l'Arduino.]]

Comparaison carte réelle/résultat Arduino:

C'était exactement les signaux attendus (même s'il y un décalage a par rapport à l'original).

On aura bien pour une QPSK (4PSK) tous les couples (ie 00,01,11 et 10).

À propos de l'arduino, on pourra envisager une amélioration pour générer une séquence plus longue:

-il faudra simplement utiliser un tableau d'entier.

-paramétrer sa taille avec un N par exemple.

-N correspondra à la taille de séquence de longueur 2^N.

Voir la section "Code Arduino réalisé" en annexe B dans la semaine correspondante.

==== Possibilités de communications: ====

Exploration des possibilités de communication entre le PC et la carte en amont:

=====-> Ethernet: =====

*+ Vitesse de transmission (~10M-100M-G)bauds

*- La gestion du flux de données doit être faite par un microcontrôleur (celui-ci pourra être implémenté un bloc I.P. à l'intérieur du FPGA)

-> - Haute consommation de CLB du FPGA.

=====-> SPI (communication série): =====

*- Vitesse de transmission

-> Arduino capable de communiquer jusqu'a 115200 bauds

-> D'après certaines discussions on pourrait « pousser » au-delà : voir le lien des sujets Raspberry Pi.

=====-> I2C : =====

Communication abandonné, ce n'est pas une priorité.

==== À propos des blocs I.P.: ====

En consultant les ordinateurs et en s'appuyant des TPs de CNP, on constate que les blocs suivants existent:

- Xilinx Microblaze/Xilinx Power PC ("µP FPGA")

-> Est-ce possible d'utiliser ces blocs I.P. pour programmer un FPGA sur une carte autre que la Nanoboard ? Comment ?

- EMACx (Ethernet Media Acess Control)(:lien physique entre processeurs et "standart Physical Layer device IEEE802.3")

===== Conception de la carte: =====

L'idéal est de se documenter sur la Compatibilité électromagnétique.

=== 2éme semaine: (du 03/02/2014 au 08/02/2014) ===

(Rien en annexe.)

=== 3éme semaine: (du 10/02/2014 au 15/02/2014) ===

Lors de cette semaine, après avoir eu le problème de manipulation, nous avons pus prendre connaissance d'un certain montage qui s’avéra utile pour la conception de la carte/maquette.

[[Fichier:P34_2013_2014_schéma_limiteur_de_courant_semaine_3.PNG|300px|thumb|center|Schéma limiteur de courant.]]

On remarquera que ce montage se retrouve dans la partie "typical application" de la documentation technique du 7805.

=== 4éme semaine: (du 17/02/2014 au 22/02/2014) ===

On souhaite pouvoir réaliser une communication unidirectionnel ou même transmettre un signal audio ce qui nous contraint à une bande passante minimal de 48kHz, on prendra 200kHz (Pour être bien au delà de la conditions du théorème de Shannon): le but serait donc de branchez par exemple une source audio quelconque puis de la transmettre à travers la maquette et de la recomposer en fin de chaine.

Après édition rapide du schématique on en dégage qu'il nous faudra un minimum d'environ 50 entrées/sorties. Mais ceci ce nombre sera très probablement revue à la hausse lors de prochaine séance.

Voici la carte que l'on utilisera dans la suite du projet:

[[Fichier:P34_2013_2014_S3BOARD-top-400_semaine_4.gif|300px|thumb|center|Digilent Spartan 3.]]

=== 5éme semaine: (du 03/03/2014 au 08/03/2014) ===

Lien vers le Design complet avec les librairies incluses (on remarquera qu'il serait judicieux d’installer toutes les librairies avant d’essayer d'ouvrir le schéma)

A notez aussi que l'on trouvera des reliques de feuilles Excel permettant de trouver rapidement des ratios dans la série E12.

[[Média:P34_2013_2014_Design_pcb_plus_librairies_semaine_5_6.zip|Schéma + Bibliothèques.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.pdf|Schéma en PDF.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.png|Schéma au format A2.]]

=== 6éme semaine: (du 10/03/2014 au 15/03/2014) ===

(Rien en annexe.)

=== 7éme semaine: (du 17/03/2014 au 22/03/2014) ===

(Rien en annexe.)

=== 8éme semaine: (du 24/03/2014 au 26/03/2014) ===

(Rien en annexe.)

=== 9éme semaine: (du 28/03/2014 au 03/04/2014) ===

[[Fichier:P34_2013_2014_DSC_0061_1_r_2r_semaine_9.jpg|center|thumb|300px|Le réseau R-2R.]]

[[Fichier:P34_2013_2014_DSC_0062_1_4QAM_semaine_9.jpg|center|thumb|300px|4QAM.]]

[[Fichier:P34_2013_2014_DSC_0066_1_16QAM_semaine_9.jpg|center|thumb|300px|16QAM.]]

[[Fichier:P34_2013_2014_DSC_0069_1_64QAM_semaine_9.jpg|center|thumb|300px|64QAM.]]

Pas de photos pour la constellation à 256 points, mais elle a été réalisée.

Pour ce qui est du montage, malgré que la P.L.L., on a un signal d'erreur après filtrage :

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Chaine 1: Vtune (commande du V.C.O.)/Chaine 2: "erreur" de commande]]

Ce qui mets en valeur immédiatement deux problèmes majeurs:

La chaine fonctionne sur le papier, mais lors de sa mise en pratique, il faut penser à mettre une tension d'offset et aussi réaliser une amplification de l'erreur pour avoir des grandeur de commande adapté au Vtune du V.C.O..

On propose l'amélioration suivante (qui sera réalisé à la prochaine séance):

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Proposition de voie d'amélioration.]]

On remarquera que les valeurs des résistances et des capacité on était choisit pour permettre un fonctionnement correct des A.O. (Amplificateur Opérationnel), mais pas pour ce qui de l'asservissement de la boucle par manque de temps.

A la fin de cette, on a eu à démonter le montage à cause de contraintes concernant les mini-circuits (car utilisé en travaux pratiques).

=== 10éme semaine: (du 07/04/2014 au 10/04/2014) ===

Spectres des signaux de la chaine de transmission:

[[Fichier:P34_2013_2014_DSC_0001_allure_spectre_reception_semaine_10.jpg|center|thumb|300px|Spectre en réception.]]

Porteuse utilisé pour la modulation I/Q à environ 60MHz.

P34_2013_2014_DSC_0001_allure_spectre_reception_semaine_10.jpg

Porteuse utilisé pour le transport en fréquence à environ 810MHz:

[[Fichier:P34_2013_2014_DSC_0035_constellation_recupere_PLL_NV_semaine_10.jpg|center|thumb|300px|"Constellation" récupéré avec la PLL défectueuse (on souhaite se verrouillé sur la raie à 868MHz).]]

Question en suspend: faudrai t'il utiliser un filtre passe bande incluant 868Mhz pour pouvoir se verrouillé sur cette fréquence ?

On remarquera sur le fait que l'oscillateur du côté de la chaine d'émission à d'importante non linéarité (on peut observer à l'analyseur de spectre 3 à 4 raies aux fréquences multiples).

Ce qui donne un diagramme de constellation plutôt mauvais si l'on fait le montage suivant:

[[Fichier:P34_2013_2014_montage_non_linearite_vco_constellation_semaine_10.PNG|center|thumb|300px|Montage réalisée.]]

[[Fichier:P34_2013_2014_sortie_montage_non_linearite_semaine_10.PNG|center|thumb|300px|La constellation 4QAM est attendu, on est loin du résultat attendu (Aucune photo n'a était réalisé d'ou le dessin).]]

== Annexe B: Digilent Spartan 3 ==

=== Procédure pour faire fonctionner la carte Digilent Spartan 3: ===

Ne connectez pas de connecteur JTAG pendant les installations. Redémarrez après chaque installation.

Tout d'abord, il faut savoir que le l'ISE Webpack 14.6 fonctionne avec la carte (n'utilisez pas la 14.7, elle ne supporte pas la génération spartan 3 !):

Installez donc l'ISE WebPack 14.6 (ou antérieur à condition que celle-ci soit supérieur à la 7.1i (d'aprés leur documentation))

(voir lien utile sur Xilinx)

Une fois l'installation de l'ISE terminé, faites en sorte d'avoir celui que soit opérationnel (la licence est gratuite !).

Installez la "library" ADEPT 2.3 voir le lien utile.

Après vous n'avez plus qu'a utilisez ISE Xilinx normalement et vous serez capable de reconnaitre la carte via la liaison JTAG, et de le programmer.

=== Liens utiles: ===

Lien constructeur/vendeur (avec ressources utiles en bas de la page):

http://www.digilentinc.com/Products/Detail.cfm?Prod=S3BOARD

Lien "Library" pour le câble USB digilent:

http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,66,69&Prod=ADEPT

Lien Xilinx (Pour l'ISE 14.6):

http://www.xilinx.com/products/design-tools/ise-design-suite/index.htm

Lien Xilinx (Pour les versions antérieures veuillez faire attention au système d'exploitation, votre architecture matérielle et le FPGA cible):

(Les informations de compatibilité son sur la page suivante:) (mots clés: xilinx classic(s))

http://www.xilinx.com/tools/classics.htm

=== Procédure pour faire une programmation en volatile: ===

Générer le bitstream, et le charger.

=== Procédure pour faire une programmation en "non"-volatile: ===

Générer le bitstream et l'utiliser pour générer un .mcs qui vous permettra d'inscrire le programme dans la mémoire (E?)PROM.

On remarquera que la programmation en non-volatile est utile pour faire un remise à zéro et recharger le contenu de l'(E?)PROM, mais semble être sensible au débranchement de l'adaptateur d'alimentation de la carte.

=== Exemple de programmation: ===

Voir le lien digilent pour ceci dans cette annexe.

Modem pour le numérique

2014-04-13T20:54:10Z

Jvaessen : /* Modulateur et démodulateur pour communications numériques */

= Modulateur et démodulateur pour communications numériques =

== Cahier des charges ==

=== Présentation générale du projet ===

Dans le cadre des TPs d'électronique et de transmission RF, nous avons découvert qu'il existe plusieurs modes de modulation, pour transmettre un signal modulant.

Celles vues en TP au S7 sont la modulation en amplitude, en fréquence, en phase, en BPSK et en QPSK.

Or les modulations en phase, en fréquence et en amplitude étant celles les plus connues, la modulation en QAM (Modulation d'Amplitude en Quadrature) est quant à elle moins connue, mais tout aussi utilisées:

-pour la TNT en 64 QAM (en France).

[[Fichier:P34_2013_2014_64qam.jpg|300px|thumb|center|Exemple de constellation 64QAM.]]

-pour le WiFi en 64-QAM ou 256-QAM (à vérifier).

Or ces deux dernières étant peu représentées au niveau des travaux pratiques, ce projet permettra de fournir un peu plus de pratique sur les modulations de type QAM (en diagramme I/Q) dans le domaine des radiofréquences (~800MHz).

(Le nombre devant le QAM indique le nombre de points dans le diagramme I/Q qu'on appelle aussi constellation)

On se réserve le droit de faire '''évoluer''' le cahier des charges a posteriori, si certaines contraintes étaient amenées à évoluer ou se préciser.

=== Objectif et intérêt du projet ===

Pour cela, on nous a fourni des modules commerciaux Mini-circuit pouvant travailler dans les radios-fréquences.

Ceux-ci permettront de mettre en place une grande partie de la chaine de transmission (voir schéma de la chaine de transmission).

[[Fichier:P34_2013_2014_Chaine_modulation.PNG|300px|thumb|center|Modulation.]]

[[Fichier:P34_2013_2014_Chaine_demodulation.PNG|300px|thumb|center|Démodulation.]]

On a tout d'abord à mettre en place une carte FPGA et/ou un dispositif permettant d'envoyer un flux de données numériques continuellement pour pouvoir visualiser le diagramme I/Q (mise en valeur du diagramme I/Q et voir même un diagramme un peu plus complexe que le BPSK ou le QPSK).

Le canal de transmission qui sera un simple fil électrique, mais pourra devenir une antenne réceptrice et émettrice si le temps imparti le permet (mise en valeur du et mesure du Bit Error Rate qui sera bien sûr différent suivant le canal de transmission).

Du côté réception ,après démodulation du signal, une remise en forme et une interprétation des données seront réalisées, celle-ci dépendra bien entendu de la provenance du flux de données (constater le succès ou l'échec d'un envoi de données).

Enfin si le temps le permets on pourra mettre en une place un système de codage de l'information avec par exemple un codage redondant permettant de corrigé l'erreur (À définir, on pourra faire constater l'efficacité d'une méthode de codage au choix).

=== Étapes/Déroulement du projet ===

De même que pour le cahier des charges, il se peut que les étapes diffèrent plus ou moins, en fonction des disponibilités, matérielles et contraintes.

==== => Caractérisation des blocs Mini-circuits et épluchage des documentations techniques====
Avant de les utiliser dans la chaine de transmission, nous avons à faire une caractérisation des blocs fournis:

-la caractérisation du VCO.

-l'étude des possibilités offerte par le modulateur (cela déterminera le nombre de points possible dans la constellation, ie savoir si l'on peut aller au-delà de la QPSK).

-la caractérisation des mélangeurs (Mixer), leurs facteurs réels de multiplication.

==== => Utilisation et exploitation des caractérisations ====
On pourra ensuite trouver les paramètres pour régler correctement dans notre chaine de transmission certains de nos sous-systèmes comme la boucle à verrouillage de phase.

==== => Génération d'un flux des données numériques ====
Comme dit précédemment, l'idéal et d'avoir un flux de données numériques transmis en permanence.
Pour cela plusieurs solutions s'offre à nous, on pourra utiliser un montage générateur pseudo aléatoire (un circuit que l'on a fait l'année dernière en Conception de Circuit Électronique).
On pourra "émuler" ce montage avec un Arduino, ou bien même le faire au moyen de la Nanoboard.
On pourra aussi transmettre des chaines de caractère en continu.

==== => Test de la chaine ====
Une fois les étapes précédentes réalisées, on pourra passer au test de la chaine de transmission. Il faudra vérifier le bon fonctionnement en aval, dedans (boucle à verrouillage de phase), et en amont de la chaine de transmission.

==== => Première mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.
Il est possible que la conception d'un dispositif soit nécessaire que ce soit pour les deux mesures du B.E.R..

==== => Antennes ====
Si toutes les étapes précédentes sont satisfaites, on pourra alors faire un canal de transmission plus intéressant, à savoir l'air.
Nous passerons alors à la conception des antennes, émettrice et réceptrice.

==== => Deuxième mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.

==== => Codage de l'information et correction d'erreur ====
En toute fin de ce projet, on pourra même mettre deux dispositifs en aval et en amont de la chaine de transmission.
On réalisera alors un codeur et un décodeur permettant de faire de la détection/correction d'erreur.

==== => Mise en place d'outil de débogage (tout au long)====
La mise en place de simples outils de débogage et primordiale, ceux-ci permettront de vérifier le bon fonctionnement de la chaine.

==== => Proposition d'un sujet de TP (tout au long) ====
Il se trouve que lors du déroulement du projet, on pourra être amené à se poser des questions au niveau des réglages de la chaine de transmission.
Or il est fort probable que les élèves qui travailleront sur ce TP pourront alors se poser les mêmes questions.
C'est pour cela qui sera judicieux de prendre soin de noter les problématiques rencontrées et de donner un certain fil de développement pour venir à bout de la problématique posée.
Ce qui reviendra à proposer des axes/questions sur les manipulations de cette maquette de TP.

== Note valable pour toutes les semaines ==

'''[[Si un point vous semble imprécis, veuillez vous reporter aux détails fournis en annexe.]]'''

== 1éme semaine: (du 27/01/2014 au 01/02/2014) ==

Séance du 05/02/2014 :

Pour bien comprendre les différentes choses à réaliser, on a refait les manipulations vues en TP. On a, pour cela utiliser la maquette didactique TIMS pour générer différent type de modulation:

-la modulation en 4,8,16PSK (on obtient une constellation en forme de cercle).

-La modulation en 4,8,16QAM (on obtient une constellation avec un carré, ou deux: de différentes tailles).

On a très vite dégagé la nécessité de réaliser un montage générateur de tous les mots numériques possibles.
On a donc fait un programme sur arduino qui équivaut au générateur pseudo aléatoire.
Celui-ci est directement inspiré du montage que l'on a réalisé l'année dernière en conception de circuit électronique.

Séance du 06/02/2014 :

Lors de cette séance on a exploré toutes les possibilités concernant la communication entre la maquette/carte, car cela pour avoir une influence non négligeable sur le choix de la carte F.P.G.A. et du design de la maquette.

On a donc aussi fait des recherches concernant les possibilités de communications et les blocs I.P. (Intellectual Properties) permettant de programmer un F.P.G.A.

Et enfin, on a eu une discussion avec un responsable technique pour ce qui de la C.E.M. (Compatibilité Electro-Magnétique)

== 2éme semaine: (du 03/02/2014 au 08/02/2014) ==

Réflexion sur les possibilités possibles et offertes par le sujet pour ce qui est des parties de communications entre la maquette en interne et de son environnement.

[[Fichier:P34_2013_2014_schéma_principe_carte_semaine_2.PNG|300px|thumb|center|Maquette en interne/externe.]]

N'ayant jamais utilisé d'autre carte que la Nanoboard, on s'est attelé à faire des recherches sur la manière de procéder pour programmer une carte F.P.G.A., il se trouve que chaque carte de développement à ses propres manières pour être programmé.

On a pris le soin de noter toutes les questions concernant le F.P.G.A. pour un intervenant industriel qui assura un cours la semaine prochaine.

== 3éme semaine: (du 10/02/2014 au 15/02/2014) ==

Ayant les oscillateurs commandables en tension, on a pu commencer à faire une manipulation avec les composants Mini-Circuit.

Mais après un problème suite à une manipulation l'un des VCOs ne fonctionne plus.

Ce qui nous amène à penser qu'il sera judicieux de prévoir une alimentation au niveau de la carte.

Celle-ci devra être inférieure ou égale à la tension maximale d'alimentation du composant (ceux-ci étant très sensible).

Questions/Réponses:

Comment fait-on pour programmer une carte F.P.G.A. est-ce que la programmation se fait "in situe" ? (in situe : c'est à dire sur la carte elle-même)
Oui, c'est ce qui est utilisé, via un câble JTAG.

Est-ce possible faire une interface USB pour permettre à un ordinateur de communiquer avec la maquette/carte via un F.P.G.A. ? Oui.

Est-ce que la gestion de l'interface Ethernet est envisageable ? Oui.

Pour une communication en protocole UDP avec un ordinateur via une liaison Ethernet, est-ce qu'il y a d'autres façons que d'utiliser un "SoftCore" ?

Oui, il existe aussi bien en Software, qu'en Hardware.

== 4éme semaine: (du 17/02/2014 au 22/02/2014) ==

On a donc repris l'idée de la 2éme semaine.

Après avoir mis en place un cahier des charges au niveau des qualités, bande passante minimale.

Nous avons fait des recherches sur les composants à utiliser (i.e. CAN, CAN, ...)

Ce qui nous a permis après une édition rapide de schéma électrique (schematic) d'avoir une idée du nombre de pins dont nous aurons besoin sur une carte FPGA afin de réaliser le projet.

Après prospection, il se trouve que nous nous dirigerions vers la carte Digilent Spartan 3, dont l'école était déjà en possession.

Donc nous nous sommes attelés à faire des recherches et des essais sur cette carte et pour notamment trouver un moyen de la faire fonctionner.

== 5éme semaine: (du 03/03/2014 au 08/03/2014) ==

Tout d'abord, après plusieurs heures de recherches et d'essai infructueux, on a fini par trouver les drivers pour le câble USB diligent.

Et donc ainsi avoir un fonctionnement de la communication via le câble JTAG plus propice au fonctionnement de la carte.

On a pu enfin se conforter sur une partie des composants et des dimensionnements pour certains d'entre eux (valeur de résistance,capacité...)

Schématics: Édition de multiple bibliothèque pour Altium, intégrant à la fois schématics et leur empreinte PCB associée.

(On a pu constater qu'une interface 3v3 5v n'est pas forcement nécessaire pour assurer le bon fonctionnement entre deux cartes avec des tensions d'alimentation différentes.)

== 6éme semaine: (du 10/03/2014 au 15/03/2014) ==

On a pu enfin se conforter sur l'ensemble des composants et des choix de régulateur et utilisation d'autre diode Zener.

On trouvera le schéma intégral avec les bibliothèques nécessaires dans la semaine 5.

Cette semaine a été dédiée à l'envoi de la commande des composants au sein du magasin de l'école et du fournisseur.

Après envoi de la commande, il se trouve que le projet a changé d'objectif principal.

Il est maintenant prioritaire de réaliser un code VHDL capable d'évaluer la vitesse de transmission numérique du côté récepteur.

== 7éme semaine: (du 17/03/2014 au 22/03/2014) ==

Pour cette semaine, on s'est concentré sur la réalisation d'un générateur pseudo aléatoire en interne au FPGA.

On réalisera une échelle de résistance afin de réaliser une conversion numérique analogique afin de l'envoyer sur la chaine de transmission.

Ce code de "base" nous permettra de réaliser un flux de données fictif pour obtenir toutes les combinaisons récupérant le résultat du bus.

[[MédiaP34_2013_2014_gene_pseudo_19_03_2014_6_semaine_7.zip|Archive contenant le projet ISE Xilinx.]]

[[Fichier:P34_2013_2014_rtl_semaine_7.PNG|300px|thumb|center|extrait du schéma RTL, on peut y voir clairement les inférences de Xilinx.]]

Ce schéma a deux entrées et une sortie, une entrée d'initialisation, une horloge et une sortie pour la trame en pseudo aléatoire.

On fera l'essai sur la carte lors de la semaine suivante.

== 8éme semaine: (du 24/03/2014 au 26/03/2014) ==

Après le premier test, on pourrait penser que l'on récupère du bruit en sortie de la carte:

[[Fichier:P34_2013_2014_DSC_0024_1_probleme_d_overshoot_semaine_8.jpg|300px|thumb|center|Overshoot.]]

Pour pouvoir remédier à ce problème, on a fait une prédivision de l'horloge

[[Fichier:P34_2013_2014_DSC_0037_1_div_freq_semaine_8.jpg|300px|thumb|center|Overshoot après division.]]

[[Fichier:P34_2013_2014_DSC_0039_1_div_freq_zoom_semaine_8.jpg|300px|thumb|center|Overshoot après division (Zoom).]]

Archive contenant toutes les modifications:

[[Média:P34_2013_2014_gene_pseudo_26_03_2014_2_semaine_8.zip|VHDL Semaine 8.]]

On a trouvé un moyen de faire un CNA facilement, via une "échelle dite R-2R". [[http://www.uchobby.com/index.php/2008/01/08/arduino-audio-dac-options/|Pour le réseau R 2R.]]

Il faut encore modifier le VHDL pour pouvoir l'exploiter et ainsi générer une constellation.

== 9éme semaine: (du 28/03/2014 au 03/04/2014) ==

On a pris donc le soin de modifier le VHDL:

[[Média:P34_2013_2014_gene_pseudo_31_03_2014_1_semaine_9.zip|VHDL semaine 9]]

Ce VHDL à été mis à jour, avec deux entrées (initialisation et une horloge) et un bus de sortie (8 bits), avec les trames pseudoaléatoires.

On envoie ces signaux sur deux C.N.A.s (4 bits chacun) pour générer deux signaux I et Q, on peut voir une constellation se dessiner en mode X-Y.

[[Fichier:P34_2013_2014_DSC_0072_1_Montage_entier_4qam_semaine_9.jpg|300px|thumb|center|Montage avec constellations 4QAM.]]

D'autres constellations réalisées sont disponibles en annexe. On peut monter jusqu'à une constellation de 256 points (2^4*2^4).

On a réalisé le montage complet de toute la chaine de transmission. Il se trouve que la Boucle à Verrouillage de Phase (ou appellée PLL, Phase Loop Locker) ne se verrouille pas sur la porteuse du signal que l'on souhaite récupéré, de ce fait on ne peut pas récupérer les signaux I et Q.

== 10éme semaine: (du 07/04/2014 au 10/04/2014) ==

On a réalisé le montage que l'on évoquait en semaine 9:

P34_2013_2014_DSC_0027_montage_realisee_semaine_10.jpg

[[Fichier:P34_2013_2014_DSC_0027_montage_realisee_semaine_10.jpg|center|thumb|300px|Montage pour améliorer la PLL.]]

Il se trouve qu’après un réglage précis de la tension d'offset permettant d'être un proche de la fréquence à capturer on obtient:

[[Fichier:P34_2013_2014_DSC_0025_PLL_non_verrouillage_semaine_10.jpg|center|thumb|300px|Signaux I/Q après ajout du montage.]]

= Annexes =

== Annexe A: Détails techniques des semaines ==

=== 1éme semaine: (du 27/01/2014 au 01/02/2014) ===

Après on a réfléchi sur la potentielle conception/utilisation d'une carte FPGA.
Il sera judicieux de ne pas se précipiter sur le schéma et la conception/utilisation d'une carte FPGA, sans avoir, au préalable fait le VHDL et le testez avec un banc de test virtuel.
L'intérêt et de mettre en valeur la nécessité ou non de certains signaux pour le schéma de la carte.
On va mettre en oeuvre les connaissances acquises au S7 en VHDL (en TP de Circuit Numérique Programmble).

Pour ce qui est de l'Arduino, on a répondu aux interrogations suivantes (certaines de ces questions paraissent triviales, mais on préfère éviter les surprises):

Quelle est la vitesse maximale de la communication série de l'Arduino ?
-115200bauds

Est-ce que, un programme de type "Analog Write" est-il une vraie sortie analogique ?

-Non, c'est juste une PWM. Elle sera exploitable pour faire les signales I/Q mais très contraignantes, car il faudra filtré le signal, et ce sera beaucoup trop lent (du au fait que la modulation est faite au alentour de 850Mhz), le FPGA sera un passage obligé cela ouvrira les portes d'un plus grand débit.

==== Manipulation réalisée sur la maquette TIMS : ====

On a fait un des montages présenté dans l'ouvrage "Volume D1 Fundamental Digital Experiments" dans le but de visualiser l’objectif à atteindre.

On obtient la constellation suivante (16QAM):

[[Fichier:P34_2013_2014_constelation_tims_semaine_1.PNG|300px|thumb|center|Constellation visualisé en mode X-Y.]]

Ce qui correspond à deux signaux en visualisation temporelle de cette forme :

[[Fichier:P34_2013_2014_constelation_temporelle_tims_semaine_1.PNG|300px|thumb|center|Signaux I et Q. (Image très flouté, à remplacer)]]

On pourra facilement obtenir le même résultat en générant un bus de trame pseudo aléatoire et en l'injectant dans un C.N.A. (Conversion Numérique Analogique)

==== Code Arduino réalisé: ====

[[Fichier:P34_2013_2014_schema_electronique_generateur_pseudo_aleatoire.png|300px|thumb|center|Schéma électronique du générateur pseudo aléatoire.]]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_chrono_simule.PNG|300px|thumb|center|Résultat de la simulation du générateur pseudo aléatoire (on a eu la même chose en pratique).]]

[code]
/*A peut être supprimer*/
#include <avr/io.h>
#include <util/delay.h>

void output_init(void){
DDRB |= 0x02; // PIN 8,9 sont les deux sorties.
}

int main(void){
int r1=1,r2=0,r3=0,r4=0,r5=0,retard=0;
PORTB=0x00;
while(1)
{
r5=r4;//chaque affectation représente une recopie de la bascule sur le "front montant", ici c'est simplement l’exécution du code.
r4=r3;
r3=r2;
r2=r1;
r1=r4^r5;
PORTB=0x01*r1+0x02*retard;//écriture des signaux
_delay_ms(10);//le "front montant", ce qui permet de faire un genre d'horloge.
retard=r5;//déphasage du signal
}
return 0;
}
[/code]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_arduino.jpg|300px|thumb|center|Resultat avec le generateur pseudo aléatoire "émuler" avec l'Arduino.]]

Comparaison carte réelle/résultat Arduino:

C'était exactement les signaux attendus (même s'il y un décalage a par rapport à l'original).

On aura bien pour une QPSK (4PSK) tous les couples (ie 00,01,11 et 10).

À propos de l'arduino, on pourra envisager une amélioration pour générer une séquence plus longue:

-il faudra simplement utiliser un tableau d'entier.

-paramétrer sa taille avec un N par exemple.

-N correspondra à la taille de séquence de longueur 2^N.

Voir la section "Code Arduino réalisé" en annexe B dans la semaine correspondante.

==== Possibilités de communications: ====

Exploration des possibilités de communication entre le PC et la carte en amont:

=====-> Ethernet: =====

*+ Vitesse de transmission (~10M-100M-G)bauds

*- La gestion du flux de données doit être faite par un microcontrôleur (celui-ci pourra être implémenté un bloc I.P. à l'intérieur du FPGA)

-> - Haute consommation de CLB du FPGA.

=====-> SPI (communication série): =====

*- Vitesse de transmission

-> Arduino capable de communiquer jusqu'a 115200 bauds

-> D'après certaines discussions on pourrait « pousser » au-delà : voir le lien des sujets Raspberry Pi.

=====-> I2C : =====

Communication abandonné, ce n'est pas une priorité.

==== À propos des blocs I.P.: ====

En consultant les ordinateurs et en s'appuyant des TPs de CNP, on constate que les blocs suivants existent:

- Xilinx Microblaze/Xilinx Power PC ("µP FPGA")

-> Est-ce possible d'utiliser ces blocs I.P. pour programmer un FPGA sur une carte autre que la Nanoboard ? Comment ?

- EMACx (Ethernet Media Acess Control)(:lien physique entre processeurs et "standart Physical Layer device IEEE802.3")

===== Conception de la carte: =====

L'idéal est de se documenter sur la Compatibilité électromagnétique.

=== 2éme semaine: (du 03/02/2014 au 08/02/2014) ===

(Rien en annexe.)

=== 3éme semaine: (du 10/02/2014 au 15/02/2014) ===

Lors de cette semaine, après avoir eu le problème de manipulation, nous avons pus prendre connaissance d'un certain montage qui s’avéra utile pour la conception de la carte/maquette.

[[Fichier:P34_2013_2014_schéma_limiteur_de_courant_semaine_3.PNG|300px|thumb|center|Schéma limiteur de courant.]]

On remarquera que ce montage se retrouve dans la partie "typical application" de la documentation technique du 7805.

=== 4éme semaine: (du 17/02/2014 au 22/02/2014) ===

On souhaite pouvoir réaliser une communication unidirectionnel ou même transmettre un signal audio ce qui nous contraint à une bande passante minimal de 48kHz, on prendra 200kHz (Pour être bien au delà de la conditions du théorème de Shannon): le but serait donc de branchez par exemple une source audio quelconque puis de la transmettre à travers la maquette et de la recomposer en fin de chaine.

Après édition rapide du schématique on en dégage qu'il nous faudra un minimum d'environ 50 entrées/sorties. Mais ceci ce nombre sera très probablement revue à la hausse lors de prochaine séance.

Voici la carte que l'on utilisera dans la suite du projet:

[[Fichier:P34_2013_2014_S3BOARD-top-400_semaine_4.gif|300px|thumb|center|Digilent Spartan 3.]]

=== 5éme semaine: (du 03/03/2014 au 08/03/2014) ===

Lien vers le Design complet avec les librairies incluses (on remarquera qu'il serait judicieux d’installer toutes les librairies avant d’essayer d'ouvrir le schéma)

A notez aussi que l'on trouvera des reliques de feuilles Excel permettant de trouver rapidement des ratios dans la série E12.

[[Média:P34_2013_2014_Design_pcb_plus_librairies_semaine_5_6.zip|Schéma + Bibliothèques.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.pdf|Schéma en PDF.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.png|Schéma au format A2.]]

=== 6éme semaine: (du 10/03/2014 au 15/03/2014) ===

(Rien en annexe.)

=== 7éme semaine: (du 17/03/2014 au 22/03/2014) ===

(Rien en annexe.)

=== 8éme semaine: (du 24/03/2014 au 26/03/2014) ===

(Rien en annexe.)

=== 9éme semaine: (du 28/03/2014 au 03/04/2014) ===

[[Fichier:P34_2013_2014_DSC_0061_1_r_2r_semaine_9.jpg|center|thumb|300px|Le réseau R-2R.]]

[[Fichier:P34_2013_2014_DSC_0062_1_4QAM_semaine_9.jpg|center|thumb|300px|4QAM.]]

[[Fichier:P34_2013_2014_DSC_0066_1_16QAM_semaine_9.jpg|center|thumb|300px|16QAM.]]

[[Fichier:P34_2013_2014_DSC_0069_1_64QAM_semaine_9.jpg|center|thumb|300px|64QAM.]]

Pas de photos pour la constellation à 256 points, mais elle a été réalisée.

Pour ce qui est du montage, malgré que la P.L.L., on a un signal d'erreur après filtrage :

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Chaine 1: Vtune (commande du V.C.O.)/Chaine 2: "erreur" de commande]]

Ce qui mets en valeur immédiatement deux problèmes majeurs:

La chaine fonctionne sur le papier, mais lors de sa mise en pratique, il faut penser à mettre une tension d'offset et aussi réaliser une amplification de l'erreur pour avoir des grandeur de commande adapté au Vtune du V.C.O..

On propose l'amélioration suivante (qui sera réalisé à la prochaine séance):

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Proposition de voie d'amélioration.]]

On remarquera que les valeurs des résistances et des capacité on était choisit pour permettre un fonctionnement correct des A.O. (Amplificateur Opérationnel), mais pas pour ce qui de l'asservissement de la boucle par manque de temps.

A la fin de cette, on a eu à démonter le montage à cause de contraintes concernant les mini-circuits (car utilisé en travaux pratiques).

=== 10éme semaine: (du 07/04/2014 au 10/04/2014) ===

Spectres des signaux de la chaine de transmission:

[[Fichier:P34_2013_2014_DSC_0001_allure_spectre_reception_semaine_10.jpg|center|thumb|300px|Spectre en réception.]]

Porteuse utilisé pour la modulation I/Q à environ 60MHz.

P34_2013_2014_DSC_0001_allure_spectre_reception_semaine_10.jpg

Porteuse utilisé pour le transport en fréquence à environ 810MHz:

[[Fichier:P34_2013_2014_DSC_0035_constellation_recupere_PLL_NV_semaine_10.jpg|center|thumb|300px|"Constellation" récupéré avec la PLL défectueuse (on souhaite se verrouillé sur la raie à 868MHz).]]

Question en suspend: faudrai t'il utiliser un filtre passe bande incluant 868Mhz pour pouvoir se verrouillé sur cette fréquence ?

On remarquera sur le fait que l'oscillateur du côté de la chaine d'émission à d'importante non linéarité (on peut observer à l'analyseur de spectre 3 à 4 raies aux fréquences multiples).

Ce qui donne un diagramme de constellation plutôt mauvais si l'on fait le montage suivant:

[[Fichier:P34_2013_2014_montage_non_linearite_vco_constellation_semaine_10.PNG|center|thumb|300px|Montage réalisée.]]

[[Fichier:P34_2013_2014_sortie_montage_non_linearite_semaine_10.PNG|center|thumb|300px|La constellation 4QAM est attendu, on est loin du résultat attendu (Aucune photo n'a était réalisé d'ou le dessin).]]

== Annexe B: Digilent Spartan 3 ==

=== Procédure pour faire fonctionner la carte Digilent Spartan 3: ===

Ne connectez pas de connecteur JTAG pendant les installations. Redémarrez après chaque installation.

Tout d'abord, il faut savoir que le l'ISE Webpack 14.6 fonctionne avec la carte (n'utilisez pas la 14.7, elle ne supporte pas la génération spartan 3 !):

Installez donc l'ISE WebPack 14.6 (ou antérieur à condition que celle-ci soit supérieur à la 7.1i (d'aprés leur documentation))

(voir lien utile sur Xilinx)

Une fois l'installation de l'ISE terminé, faites en sorte d'avoir celui que soit opérationnel (la licence est gratuite !).

Installez la "library" ADEPT 2.3 voir le lien utile.

Après vous n'avez plus qu'a utilisez ISE Xilinx normalement et vous serez capable de reconnaitre la carte via la liaison JTAG, et de le programmer.

=== Liens utiles: ===

Lien constructeur/vendeur (avec ressources utiles en bas de la page):

http://www.digilentinc.com/Products/Detail.cfm?Prod=S3BOARD

Lien "Library" pour le câble USB digilent:

http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,66,69&Prod=ADEPT

Lien Xilinx (Pour l'ISE 14.6):

http://www.xilinx.com/products/design-tools/ise-design-suite/index.htm

Lien Xilinx (Pour les versions antérieures veuillez faire attention au système d'exploitation, votre architecture matérielle et le FPGA cible):

(Les informations de compatibilité son sur la page suivante:) (mots clés: xilinx classic(s))

http://www.xilinx.com/tools/classics.htm

=== Procédure pour faire une programmation en volatile: ===

Générer le bitstream, et le charger.

=== Procédure pour faire une programmation en "non"-volatile: ===

Générer le bitstream et l'utiliser pour générer un .mcs qui vous permettra d'inscrire le programme dans la mémoire (E?)PROM.

On remarquera que la programmation en non-volatile est utile pour faire un remise à zéro et recharger le contenu de l'(E?)PROM, mais semble être sensible au débranchement de l'adaptateur d'alimentation de la carte.

=== Exemple de programmation: ===

Voir le lien digilent pour ceci dans cette annexe.

Modem pour le numérique

2014-04-13T20:44:47Z

Jvaessen : /* 10éme semaine: (rédaction en cours) (du 07/04/2014 au 10/04/2014) */

= Modulateur et démodulateur pour communications numériques =

== Cahier des charges ==

=== Présentation générale du projet ===

Dans le cadre des TPs d'électronique et de transmission RF, nous avons découvert qu'il existe plusieurs modes de modulation, pour transmettre un signal modulant.

Celles vues en TP au S7 sont la modulation en amplitude, en fréquence, en phase, en BPSK et en QPSK.

Or les modulations en phase, en fréquence et en amplitude étant celles les plus connues, la modulation en QAM (Modulation d'Amplitude en Quadrature) est quant à elle moins connue, mais tout aussi utilisées:

-pour la TNT en 64 QAM (en France).

[[Fichier:P34_2013_2014_64qam.jpg|300px|thumb|center|Exemple de constellation 64QAM.]]

-pour le WiFi en 64-QAM ou 256-QAM (à vérifier).

Or ces deux dernières étant peu représentées au niveau des travaux pratiques, ce projet permettra de fournir un peu plus de pratique sur les modulations de type QAM (en diagramme I/Q) dans le domaine des radiofréquences (~800MHz).

(Le nombre devant le QAM indique le nombre de points dans le diagramme I/Q qu'on appelle aussi constellation)

On se réserve le droit de faire '''évoluer''' le cahier des charges a posteriori, si certaines contraintes étaient amenées à évoluer ou se préciser.

=== Objectif et intérêt du projet ===

Pour cela, on nous a fourni des modules commerciaux Mini-circuit pouvant travailler dans les radios-fréquences.

Ceux-ci permettront de mettre en place une grande partie de la chaine de transmission (voir schéma de la chaine de transmission).

[[Fichier:P34_2013_2014_Chaine_modulation.PNG|300px|thumb|center|Modulation.]]

[[Fichier:P34_2013_2014_Chaine_demodulation.PNG|300px|thumb|center|Demodulation.]]

On a tout d'abord à mettre en place une carte FPGA et/ou un dispositif permettant d'envoyer un flux de données numériques continuellement pour pouvoir visualiser le diagramme I/Q (mise en valeur du diagramme I/Q et voir même un diagramme un peu plus complexe que le BPSK ou le QPSK).

Le canal de transmission qui sera un simple fil électrique, mais pourra devenir une antenne réceptrice et émettrice si le temps imparti le permet (mise en valeur du et mesure du Bit Error Rate qui sera bien sûr différent suivant le canal de transmission).

Du côté réception ,après démodulation du signal, une remise en forme et une interprétation des données seront réalisées, celle-ci dépendra bien entendu de la provenance du flux de données (constater le succès ou l'échec d'un envoi de données).

Enfin si le temps le permets on pourra mettre en une place un système de codage de l'information avec par exemple un codage redondant permettant de corrigé l'erreur (À définir, on pourra faire constater l'efficacité d'une méthode de codage au choix).

=== Étapes/Déroulement du projet ===

De même que pour le cahier des charges, il se peut que les étapes diffèrent plus ou moins, en fonction des disponibilités, matérielles et contraintes.

==== => Caractérisation des blocs Mini-circuits et épluchage des documentations techniques====
Avant de les utiliser dans la chaine de transmission, nous avons à faire une caractérisation des blocs fournis:

-la caractérisation du VCO.

-l'étude des possibilités offerte par le modulateur (cela déterminera le nombre de points possible dans la constellation, ie savoir si l'on peut aller au-delà de la QPSK).

-la caractérisation des mélangeurs (Mixer), leurs facteurs réels de multiplication.

==== => Utilisation et exploitation des caractérisations ====
On pourra ensuite trouver les paramètres pour régler correctement dans notre chaine de transmission certains de nos sous-systèmes comme la boucle à verrouillage de phase.

==== => Génération d'un flux des données numériques ====
Comme dit précédemment, l'idéal et d'avoir un flux de données numériques transmis en permanence.
Pour cela plusieurs solutions s'offre à nous, on pourra utiliser un montage générateur pseudo aléatoire (un circuit que l'on a fait l'année dernière en Conception de Circuit Électronique).
On pourra "émuler" ce montage avec un Arduino, ou bien même le faire au moyen de la Nanoboard.
On pourra aussi transmettre des chaines de caractère en continu.

==== => Test de la chaine ====
Une fois les étapes précédentes réalisées, on pourra passer au test de la chaine de transmission. Il faudra vérifier le bon fonctionnement en aval, dedans (boucle a verrouillage de phase), et en amont de la chaine de transmission.

==== => Première mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.
Il est possible que la conception d'un dispositif soit nécessaire que ce soit pour les deux mesures du B.E.R..

==== => Antennes ====
Si toutes les étapes précédentes sont satisfaites, on pourra alors faire un canal de transmission plus intéressant, à savoir l'air.
Nous passerons alors à la conception des antennes, émettrice et réceptrice.

==== => Deuxième mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.

==== => Codage de l'information et correction d'erreur ====
En toute fin de ce projet, on pourra même mettre deux dispositifs en aval et en amont de la chaine de transmission.
On réalisera alors un codeur et un décodeur permettant de faire de la détection/correction d'erreur.

==== => Mise en place d'outil de débogage (tout au long)====
La mise en place de simples outils de débogage et primordiale, ceux-ci permettront de vérifier le bon fonctionnement de la chaine.

==== => Proposition d'un sujet de TP (tout au long) ====
Il se trouve que lors du déroulement du projet, on pourra être amené à se poser des questions au niveau des réglages de la chaine de transmission.
Or il est fort probable que les élèves qui travailleront sur ce TP pourront alors se poser les mêmes questions.
C'est pour cela qui sera judicieux de prendre soin de noter les problématiques rencontrées et de donner un certain fil de développement pour venir à bout de la problématique posée.
Ce qui reviendra à proposer des axes/questions sur les manipulations de cette maquette de TP.

== Note valable pour toutes les semaines ==

'''[[Si un point vous semble imprécis, veuillez vous reportez aux détails fournit en annexe.]]'''

== 1éme semaine: (du 27/01/2014 au 01/02/2014) ==

Séance du 05/02/2014 :

Pour bien comprendre les différentes choses à réaliser, on a refait les manipulations vues en TP. On a, pour cela utiliser la maquette didactique TIMS pour générer différent type de modulation:

-la modulation en 4,8,16PSK (on obtient une constellation en forme de cercle).

-La modulation en 4,8,16QAM (on obtient une constellation avec un carré, ou deux: de différentes tailles).

On a très vite dégagé la nécessité de réaliser un montage générateur de tous les mots numériques possibles.
On a donc fait un programme sur arduino qui équivaut au générateur pseudo aléatoire.
Celui-ci est directement inspiré du montage que l'on a réalisé l'année dernière en conception de circuit électronique.

Séance du 06/02/2014 :

Lors de cette séance on a exploré toute les possibilités concernant la communication entre la maquette/carte car cela pour avoir une influecnce non négligeable sur le choix de la carte F.P.G.A. et du design de la maquette.

On a donc aussi fait des recherches concernant les possibilités de communications et les bloc I.P. (Intellectual Properties) permettant de programmer un F.P.G.A.

Et enfin, on a eu une discussion avec un responsable technique pour ce qui de la C.E.M. (Compatibilité Electro-Magnétique)

== 2éme semaine: (du 03/02/2014 au 08/02/2014) ==

Réflexion sur les possibilités possibles et offertes par le sujet pour ce qui est des parties de communications entre la maquette en interne et de son environnement.

[[Fichier:P34_2013_2014_schéma_principe_carte_semaine_2.PNG|300px|thumb|center|Maquette en interne/externe.]]

N'ayant jamais utilisé d'autre carte que la Nanoboard, on s'est attelé à faire des recherches sur la manière de procéder pour programmer une carte F.P.G.A., il se trouve que chaque carte de développement à ses propes manières pour être programmé.

On a pris le soin de notez toutes les questions concernant le F.P.G.A. pour un intervenant industrielle qui assura un cours la semaine prochaine.

== 3éme semaine: (du 10/02/2014 au 15/02/2014) ==

Ayant les oscillateurs commandables en tension, on a pu commencer à faire une manipulation avec les composants Mini Circuit.

Mais après un problème suite à une manipulation l'un des VCOs ne fonctionne plus.

Ce qui nous amène à penser qu'il sera judicieux de prévoir une alimentation au niveau de la carte.

Celle-ci devra être inférieure ou égale à la tension maximale d'alimentation du composant (ceux-ci étant très sensible).

Questions/Réponses:

Comment fait-on pour programmer une carte F.P.G.A. est-ce que la programmation se fait "in situe" ? (in situe : c'est à dire sur la carte elle même)
Oui, c'est ce qui est utilisé, via une câble JTAG.

Est-ce possible faire une interface USB pour permettre à un ordinateur de communiquer avec la maquette/carte via un F.P.G.A. ? Oui.

Est-ce que la gestion de l'interface Ethernet est envisageable ? Oui.

Pour une communication en protocole UDP avec un ordinateur via une liaison Ethernet, est-ce qu'il y a d'autre façon que d'utiliser un Soft Core ?

Oui, il existe aussi bien en Software, qu'en Hardware.

== 4éme semaine: (du 17/02/2014 au 22/02/2014) ==

On a donc repris l'idée de la 2éme semaine.

Après avoir mis en place un cahier des charges au niveau des qualités, bande passante minimale.

Nous avons fait des recherches sur les composants à utiliser (ie CAN, CAN, ...)

Ce qui nous a permis après une édition rapide de schéma électrique (schematic) d'avoir une idée du nombre de pins dont nous aurons besoin sur une carte FPGA afin de réaliser le projet.

Après prospection, il se trouve que nous nous dirigerions vers la carte Digilent Spartan 3, dont l'école était déjà en possession.

Donc nous nous sommes attelés à faire des recherches et des essais sur cette carte et pour notamment trouver un moyen de la faire fonctionner.

== 5éme semaine: (du 03/03/2014 au 08/03/2014) ==

Tout d'abord, après plusieurs heures de recherches et d'essai infructueux, on a fini par trouver les drivers pour le câble USB diligent.

Et donc ainsi avoir un fonctionnement de la communication via le câble JTAG plus propice au fonctionnement de la carte.

On a pu enfin se conforter sur une partie des composants et des dimensionnements pour certains d'entre eux (valeur de résistance,capacité...)

Schématics: Édition de multiple bibliothèque pour Altium, intégrant à la fois schématics et leur empreinte PCB associés.

(On a pu constater qu'un interface 3v3 5v n'est pas forcement nécessaire pour assurer le bon fonctionnement entre deux cartes avec des tensions d'alimentation différentes.)

== 6éme semaine: (du 10/03/2014 au 15/03/2014) ==

On a pu enfin se conforter sur l'ensemble des composants et des choix de régulateur et utilisation d'autre diode Zener.

On trouvera le schéma intégrale avec les bibliothèques nécessaires dans la semaine 5.

Cette semaine à été dédié à l'envoie de la commande des composants au sein du magasin de l'école et du fournisseur.

Après envoi de la commande, il se trouve que le projet a changé d'objectif principal.

Il est maintenant prioritaire de réaliser un code VHDL capable d'évaluer la vitesse de transmission numérique du côté récepteur.

== 7éme semaine: (du 17/03/2014 au 22/03/2014) ==

Pour cette semaine, on s'est concentré sur la réalisation d'un générateur pseudo aléatoire en interne au FPGA.

On réalisera une échelle de résistance afin de réaliser une conversion numérique analogique afin de l'envoyer sur la chaine de transmission.

Ce code de "base" nous permettra de réaliser un flux de données fictif pour obtenir toutes les combinaisons récupérant le résultat du bus.

[[MédiaP34_2013_2014_gene_pseudo_19_03_2014_6_semaine_7.zip|Archive contenant le projet ISE Xilinx.]]

[[Fichier:P34_2013_2014_rtl_semaine_7.PNG|300px|thumb|center|extrait du schéma RTL, on peut y voir clairement les inférences de Xilinx.]]

Ce schéma a deux entrées et une sortie, une entrée d'initialisation, une horloge et une sortie pour la trame en pseudo aléatoire.

On fera l'essaie sur la carte lors de la semaine suivante.

== 8éme semaine: (du 24/03/2014 au 26/03/2014) ==

Aprés le premier test, on pourrait penser que l'on récupère du bruit en sortie de la carte:

[[Fichier:P34_2013_2014_DSC_0024_1_probleme_d_overshoot_semaine_8.jpg|300px|thumb|center|Overshoot.]]

Pour pouvoir remédier à ce problème on a fait une pré-division de l'horloge

[[Fichier:P34_2013_2014_DSC_0037_1_div_freq_semaine_8.jpg|300px|thumb|center|Overshoot après division.]]

[[Fichier:P34_2013_2014_DSC_0039_1_div_freq_zoom_semaine_8.jpg|300px|thumb|center|Overshoot après division (Zoom).]]

Archive contenant toutes les modifications:

[[Média:P34_2013_2014_gene_pseudo_26_03_2014_2_semaine_8.zip|VHDL Semaine 8.]]

On a trouvé un moyen de faire un CNA facilement, via une "échelle dit R-2R". [[http://www.uchobby.com/index.php/2008/01/08/arduino-audio-dac-options/|Pour le réseau R 2R.]]

Il faut encore modifier le VHDL pour pouvoir l'exploiter et ainsi générer une constellation.

== 9éme semaine: (du 28/03/2014 au 03/04/2014) ==

On a pris donc le soin de modifier le VHDL:

[[Média:P34_2013_2014_gene_pseudo_31_03_2014_1_semaine_9.zip|VHDL semaine 9]]

Ce VHDL à été mis à jour, avec deux entrées (initialisation et une horloge) et un bus de sortie (8 bits), avec les trames pseudo-aléatoire.

On envoie ces signaux sur deux C.N.A.s (4 bits chacun) pour générer deux signaux I et Q, on peut voir une constellation se dessiner en mode X-Y.

[[Fichier:P34_2013_2014_DSC_0072_1_Montage_entier_4qam_semaine_9.jpg|300px|thumb|center|Montage avec constellations 4QAM.]]

D'autre constellations réalisées sont disponibles en annexe. On peut monter jusqu'à une constellation de 256 points (2^4*2^4).

On a réalisé le montage complet de toute la chaine de transmission. Il se trouve que la Boucle à Verrouillage de Phase (ou appellée PLL, Phase Loop Locker) ne se verrouille pas sur la porteuse du signal que l'on souhaite récupéré, de ce fait on ne peut pas récupérer les signaux I et Q.

== 10éme semaine: (du 07/04/2014 au 10/04/2014) ==

On a réalisé le montage que l'on évoqué en semaine 9:

P34_2013_2014_DSC_0027_montage_realisee_semaine_10.jpg

[[Fichier:P34_2013_2014_DSC_0027_montage_realisee_semaine_10.jpg|center|thumb|300px|Montage pour amélioré la PLL.]]

Il se trouve qu’après un réglage précis de la tension d'offset permettant d'être un proche de la fréquence à capturé on obtient:

[[Fichier:P34_2013_2014_DSC_0025_PLL_non_verrouillage_semaine_10.jpg|center|thumb|300px|Signaux I/Q après ajout du montage.]]

= Annexes =

== Annexe A: Détails techniques des semaines ==

=== 1éme semaine: (du 27/01/2014 au 01/02/2014) ===

Après on a réfléchi sur la potentielle conception/utilisation d'une carte FPGA.
Il sera judicieux de ne pas se précipiter sur le schéma et la conception/utilisation d'une carte FPGA, sans avoir, au préalable fait le VHDL et le testez avec un banc de test virtuel.
L'intérêt et de mettre en valeur la nécessité ou non de certains signaux pour le schéma de la carte.
On va mettre en oeuvre les connaissances acquises au S7 en VHDL (en TP de Circuit Numérique Programmble).

Pour ce qui est de l'Arduino, on a répondu aux interrogations suivantes (certaines de ces questions paraissent triviales, mais on préfère éviter les surprises):

Quelle est la vitesse maximale de la communication série de l'Arduino ?
-115200bauds

Est-ce que, un programme de type "Analog Write" est-il une vraie sortie analogique ?

-Non, c'est juste une PWM. Elle sera exploitable pour faire les signales I/Q mais très contraignantes, car il faudra filtré le signal, et ce sera beaucoup trop lent (du au fait que la modulation est faite au alentour de 850Mhz), le FPGA sera un passage obligé cela ouvrira les portes d'un plus grand débit.

==== Manipulation réalisée sur la maquette TIMS : ====

On a fait un des montages présenté dans l'ouvrage "Volume D1 Fundamental Digital Experiments" dans le but de visualiser l’objectif à atteindre.

On obtient la constellation suivante (16QAM):

[[Fichier:P34_2013_2014_constelation_tims_semaine_1.PNG|300px|thumb|center|Constellation visualisé en mode X-Y.]]

Ce qui correspond à deux signaux en visualisation temporelle de cette forme :

[[Fichier:P34_2013_2014_constelation_temporelle_tims_semaine_1.PNG|300px|thumb|center|Signaux I et Q. (Image très flouté, à remplacer)]]

On pourra facilement obtenir le même résultat en générant un bus de trame pseudo aléatoire et en l'injectant dans un C.N.A. (Conversion Numérique Analogique)

==== Code Arduino réalisé: ====

[[Fichier:P34_2013_2014_schema_electronique_generateur_pseudo_aleatoire.png|300px|thumb|center|Schéma électronique du générateur pseudo aléatoire.]]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_chrono_simule.PNG|300px|thumb|center|Résultat de la simulation du générateur pseudo aléatoire (on a eu la même chose en pratique).]]

[code]
/*A peut être supprimer*/
#include <avr/io.h>
#include <util/delay.h>

void output_init(void){
DDRB |= 0x02; // PIN 8,9 sont les deux sorties.
}

int main(void){
int r1=1,r2=0,r3=0,r4=0,r5=0,retard=0;
PORTB=0x00;
while(1)
{
r5=r4;//chaque affectation représente une recopie de la bascule sur le "front montant", ici c'est simplement l’exécution du code.
r4=r3;
r3=r2;
r2=r1;
r1=r4^r5;
PORTB=0x01*r1+0x02*retard;//écriture des signaux
_delay_ms(10);//le "front montant", ce qui permet de faire un genre d'horloge.
retard=r5;//déphasage du signal
}
return 0;
}
[/code]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_arduino.jpg|300px|thumb|center|Resultat avec le generateur pseudo aléatoire "émuler" avec l'Arduino.]]

Comparaison carte réelle/résultat Arduino:

C'était exactement les signaux attendus (même s'il y un décalage a par rapport à l'original).

On aura bien pour une QPSK (4PSK) tous les couples (ie 00,01,11 et 10).

À propos de l'arduino, on pourra envisager une amélioration pour générer une séquence plus longue:

-il faudra simplement utiliser un tableau d'entier.

-paramétrer sa taille avec un N par exemple.

-N correspondra à la taille de séquence de longueur 2^N.

Voir la section "Code Arduino réalisé" en annexe B dans la semaine correspondante.

==== Possibilités de communications: ====

Exploration des possibilités de communication entre le PC et la carte en amont:

=====-> Ethernet: =====

*+ Vitesse de transmission (~10M-100M-G)bauds

*- La gestion du flux de données doit être faite par un microcontrôleur (celui-ci pourra être implémenté un bloc I.P. à l'intérieur du FPGA)

-> - Haute consommation de CLB du FPGA.

=====-> SPI (communication série): =====

*- Vitesse de transmission

-> Arduino capable de communiquer jusqu'a 115200 bauds

-> D'après certaines discussions on pourrait « pousser » au-delà : voir le lien des sujets Raspberry Pi.

=====-> I2C : =====

Communication abandonné, ce n'est pas une priorité.

==== À propos des blocs I.P.: ====

En consultant les ordinateurs et en s'appuyant des TPs de CNP, on constate que les blocs suivants existent:

- Xilinx Microblaze/Xilinx Power PC ("µP FPGA")

-> Est-ce possible d'utiliser ces blocs I.P. pour programmer un FPGA sur une carte autre que la Nanoboard ? Comment ?

- EMACx (Ethernet Media Acess Control)(:lien physique entre processeurs et "standart Physical Layer device IEEE802.3")

===== Conception de la carte: =====

L'idéal est de se documenter sur la Compatibilité électromagnétique.

=== 2éme semaine: (du 03/02/2014 au 08/02/2014) ===

(Rien en annexe.)

=== 3éme semaine: (du 10/02/2014 au 15/02/2014) ===

Lors de cette semaine, après avoir eu le problème de manipulation, nous avons pus prendre connaissance d'un certain montage qui s’avéra utile pour la conception de la carte/maquette.

[[Fichier:P34_2013_2014_schéma_limiteur_de_courant_semaine_3.PNG|300px|thumb|center|Schéma limiteur de courant.]]

On remarquera que ce montage se retrouve dans la partie "typical application" de la documentation technique du 7805.

=== 4éme semaine: (du 17/02/2014 au 22/02/2014) ===

On souhaite pouvoir réaliser une communication unidirectionnel ou même transmettre un signal audio ce qui nous contraint à une bande passante minimal de 48kHz, on prendra 200kHz (Pour être bien au delà de la conditions du théorème de Shannon): le but serait donc de branchez par exemple une source audio quelconque puis de la transmettre à travers la maquette et de la recomposer en fin de chaine.

Après édition rapide du schématique on en dégage qu'il nous faudra un minimum d'environ 50 entrées/sorties. Mais ceci ce nombre sera très probablement revue à la hausse lors de prochaine séance.

Voici la carte que l'on utilisera dans la suite du projet:

[[Fichier:P34_2013_2014_S3BOARD-top-400_semaine_4.gif|300px|thumb|center|Digilent Spartan 3.]]

=== 5éme semaine: (du 03/03/2014 au 08/03/2014) ===

Lien vers le Design complet avec les librairies incluses (on remarquera qu'il serait judicieux d’installer toutes les librairies avant d’essayer d'ouvrir le schéma)

A notez aussi que l'on trouvera des reliques de feuilles Excel permettant de trouver rapidement des ratios dans la série E12.

[[Média:P34_2013_2014_Design_pcb_plus_librairies_semaine_5_6.zip|Schéma + Bibliothèques.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.pdf|Schéma en PDF.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.png|Schéma au format A2.]]

=== 6éme semaine: (du 10/03/2014 au 15/03/2014) ===

(Rien en annexe.)

=== 7éme semaine: (du 17/03/2014 au 22/03/2014) ===

(Rien en annexe.)

=== 8éme semaine: (du 24/03/2014 au 26/03/2014) ===

(Rien en annexe.)

=== 9éme semaine: (du 28/03/2014 au 03/04/2014) ===

[[Fichier:P34_2013_2014_DSC_0061_1_r_2r_semaine_9.jpg|center|thumb|300px|Le réseau R-2R.]]

[[Fichier:P34_2013_2014_DSC_0062_1_4QAM_semaine_9.jpg|center|thumb|300px|4QAM.]]

[[Fichier:P34_2013_2014_DSC_0066_1_16QAM_semaine_9.jpg|center|thumb|300px|16QAM.]]

[[Fichier:P34_2013_2014_DSC_0069_1_64QAM_semaine_9.jpg|center|thumb|300px|64QAM.]]

Pas de photos pour la constellation à 256 points, mais elle a été réalisée.

Pour ce qui est du montage, malgré que la P.L.L., on a un signal d'erreur après filtrage :

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Chaine 1: Vtune (commande du V.C.O.)/Chaine 2: "erreur" de commande]]

Ce qui mets en valeur immédiatement deux problèmes majeurs:

La chaine fonctionne sur le papier, mais lors de sa mise en pratique, il faut penser à mettre une tension d'offset et aussi réaliser une amplification de l'erreur pour avoir des grandeur de commande adapté au Vtune du V.C.O..

On propose l'amélioration suivante (qui sera réalisé à la prochaine séance):

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Proposition de voie d'amélioration.]]

On remarquera que les valeurs des résistances et des capacité on était choisit pour permettre un fonctionnement correct des A.O. (Amplificateur Opérationnel), mais pas pour ce qui de l'asservissement de la boucle par manque de temps.

A la fin de cette, on a eu à démonter le montage à cause de contraintes concernant les mini-circuits (car utilisé en travaux pratiques).

=== 10éme semaine: (du 07/04/2014 au 10/04/2014) ===

Spectres des signaux de la chaine de transmission:

[[Fichier:P34_2013_2014_DSC_0001_allure_spectre_reception_semaine_10.jpg|center|thumb|300px|Spectre en réception.]]

Porteuse utilisé pour la modulation I/Q à environ 60MHz.

P34_2013_2014_DSC_0001_allure_spectre_reception_semaine_10.jpg

Porteuse utilisé pour le transport en fréquence à environ 810MHz:

[[Fichier:P34_2013_2014_DSC_0035_constellation_recupere_PLL_NV_semaine_10.jpg|center|thumb|300px|"Constellation" récupéré avec la PLL défectueuse (on souhaite se verrouillé sur la raie à 868MHz).]]

Question en suspend: faudrai t'il utiliser un filtre passe bande incluant 868Mhz pour pouvoir se verrouillé sur cette fréquence ?

On remarquera sur le fait que l'oscillateur du côté de la chaine d'émission à d'importante non linéarité (on peut observer à l'analyseur de spectre 3 à 4 raies aux fréquences multiples).

Ce qui donne un diagramme de constellation plutôt mauvais si l'on fait le montage suivant:

[[Fichier:P34_2013_2014_montage_non_linearite_vco_constellation_semaine_10.PNG|center|thumb|300px|Montage réalisée.]]

[[Fichier:P34_2013_2014_sortie_montage_non_linearite_semaine_10.PNG|center|thumb|300px|La constellation 4QAM est attendu, on est loin du résultat attendu (Aucune photo n'a était réalisé d'ou le dessin).]]

== Annexe B: Digilent Spartan 3 ==

=== Procédure pour faire fonctionner la carte Digilent Spartan 3: ===

Ne connectez pas de connecteur JTAG pendant les installations. Redémarrez après chaque installation.

Tout d'abord, il faut savoir que le l'ISE Webpack 14.6 fonctionne avec la carte (n'utilisez pas la 14.7, elle ne supporte pas la génération spartan 3 !):

Installez donc l'ISE WebPack 14.6 (ou antérieur à condition que celle-ci soit supérieur à la 7.1i (d'aprés leur documentation))

(voir lien utile sur Xilinx)

Une fois l'installation de l'ISE terminé, faites en sorte d'avoir celui que soit opérationnel (la licence est gratuite !).

Installez la "library" ADEPT 2.3 voir le lien utile.

Après vous n'avez plus qu'a utilisez ISE Xilinx normalement et vous serez capable de reconnaitre la carte via la liaison JTAG, et de le programmer.

=== Liens utiles: ===

Lien constructeur/vendeur (avec ressources utiles en bas de la page):

http://www.digilentinc.com/Products/Detail.cfm?Prod=S3BOARD

Lien "Library" pour le câble USB digilent:

http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,66,69&Prod=ADEPT

Lien Xilinx (Pour l'ISE 14.6):

http://www.xilinx.com/products/design-tools/ise-design-suite/index.htm

Lien Xilinx (Pour les versions antérieures veuillez faire attention au système d'exploitation, votre architecture matérielle et le FPGA cible):

(Les informations de compatibilité son sur la page suivante:) (mots clés: xilinx classic(s))

http://www.xilinx.com/tools/classics.htm

=== Procédure pour faire une programmation en volatile: ===

Générer le bitstream, et le charger.

=== Procédure pour faire une programmation en "non"-volatile: ===

Générer le bitstream et l'utiliser pour générer un .mcs qui vous permettra d'inscrire le programme dans la mémoire (E?)PROM.

On remarquera que la programmation en non-volatile est utile pour faire un remise à zéro et recharger le contenu de l'(E?)PROM, mais semble être sensible au débranchement de l'adaptateur d'alimentation de la carte.

=== Exemple de programmation: ===

Voir le lien digilent pour ceci dans cette annexe.

Modem pour le numérique

2014-04-13T20:43:44Z

Jvaessen : /* 10éme semaine: (rédaction en cours) (du 07/04/2014 au 10/04/2014) */

= Modulateur et démodulateur pour communications numériques =

== Cahier des charges ==

=== Présentation générale du projet ===

Dans le cadre des TPs d'électronique et de transmission RF, nous avons découvert qu'il existe plusieurs modes de modulation, pour transmettre un signal modulant.

Celles vues en TP au S7 sont la modulation en amplitude, en fréquence, en phase, en BPSK et en QPSK.

Or les modulations en phase, en fréquence et en amplitude étant celles les plus connues, la modulation en QAM (Modulation d'Amplitude en Quadrature) est quant à elle moins connue, mais tout aussi utilisées:

-pour la TNT en 64 QAM (en France).

[[Fichier:P34_2013_2014_64qam.jpg|300px|thumb|center|Exemple de constellation 64QAM.]]

-pour le WiFi en 64-QAM ou 256-QAM (à vérifier).

Or ces deux dernières étant peu représentées au niveau des travaux pratiques, ce projet permettra de fournir un peu plus de pratique sur les modulations de type QAM (en diagramme I/Q) dans le domaine des radiofréquences (~800MHz).

(Le nombre devant le QAM indique le nombre de points dans le diagramme I/Q qu'on appelle aussi constellation)

On se réserve le droit de faire '''évoluer''' le cahier des charges a posteriori, si certaines contraintes étaient amenées à évoluer ou se préciser.

=== Objectif et intérêt du projet ===

Pour cela, on nous a fourni des modules commerciaux Mini-circuit pouvant travailler dans les radios-fréquences.

Ceux-ci permettront de mettre en place une grande partie de la chaine de transmission (voir schéma de la chaine de transmission).

[[Fichier:P34_2013_2014_Chaine_modulation.PNG|300px|thumb|center|Modulation.]]

[[Fichier:P34_2013_2014_Chaine_demodulation.PNG|300px|thumb|center|Demodulation.]]

On a tout d'abord à mettre en place une carte FPGA et/ou un dispositif permettant d'envoyer un flux de données numériques continuellement pour pouvoir visualiser le diagramme I/Q (mise en valeur du diagramme I/Q et voir même un diagramme un peu plus complexe que le BPSK ou le QPSK).

Le canal de transmission qui sera un simple fil électrique, mais pourra devenir une antenne réceptrice et émettrice si le temps imparti le permet (mise en valeur du et mesure du Bit Error Rate qui sera bien sûr différent suivant le canal de transmission).

Du côté réception ,après démodulation du signal, une remise en forme et une interprétation des données seront réalisées, celle-ci dépendra bien entendu de la provenance du flux de données (constater le succès ou l'échec d'un envoi de données).

Enfin si le temps le permets on pourra mettre en une place un système de codage de l'information avec par exemple un codage redondant permettant de corrigé l'erreur (À définir, on pourra faire constater l'efficacité d'une méthode de codage au choix).

=== Étapes/Déroulement du projet ===

De même que pour le cahier des charges, il se peut que les étapes diffèrent plus ou moins, en fonction des disponibilités, matérielles et contraintes.

==== => Caractérisation des blocs Mini-circuits et épluchage des documentations techniques====
Avant de les utiliser dans la chaine de transmission, nous avons à faire une caractérisation des blocs fournis:

-la caractérisation du VCO.

-l'étude des possibilités offerte par le modulateur (cela déterminera le nombre de points possible dans la constellation, ie savoir si l'on peut aller au-delà de la QPSK).

-la caractérisation des mélangeurs (Mixer), leurs facteurs réels de multiplication.

==== => Utilisation et exploitation des caractérisations ====
On pourra ensuite trouver les paramètres pour régler correctement dans notre chaine de transmission certains de nos sous-systèmes comme la boucle à verrouillage de phase.

==== => Génération d'un flux des données numériques ====
Comme dit précédemment, l'idéal et d'avoir un flux de données numériques transmis en permanence.
Pour cela plusieurs solutions s'offre à nous, on pourra utiliser un montage générateur pseudo aléatoire (un circuit que l'on a fait l'année dernière en Conception de Circuit Électronique).
On pourra "émuler" ce montage avec un Arduino, ou bien même le faire au moyen de la Nanoboard.
On pourra aussi transmettre des chaines de caractère en continu.

==== => Test de la chaine ====
Une fois les étapes précédentes réalisées, on pourra passer au test de la chaine de transmission. Il faudra vérifier le bon fonctionnement en aval, dedans (boucle a verrouillage de phase), et en amont de la chaine de transmission.

==== => Première mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.
Il est possible que la conception d'un dispositif soit nécessaire que ce soit pour les deux mesures du B.E.R..

==== => Antennes ====
Si toutes les étapes précédentes sont satisfaites, on pourra alors faire un canal de transmission plus intéressant, à savoir l'air.
Nous passerons alors à la conception des antennes, émettrice et réceptrice.

==== => Deuxième mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.

==== => Codage de l'information et correction d'erreur ====
En toute fin de ce projet, on pourra même mettre deux dispositifs en aval et en amont de la chaine de transmission.
On réalisera alors un codeur et un décodeur permettant de faire de la détection/correction d'erreur.

==== => Mise en place d'outil de débogage (tout au long)====
La mise en place de simples outils de débogage et primordiale, ceux-ci permettront de vérifier le bon fonctionnement de la chaine.

==== => Proposition d'un sujet de TP (tout au long) ====
Il se trouve que lors du déroulement du projet, on pourra être amené à se poser des questions au niveau des réglages de la chaine de transmission.
Or il est fort probable que les élèves qui travailleront sur ce TP pourront alors se poser les mêmes questions.
C'est pour cela qui sera judicieux de prendre soin de noter les problématiques rencontrées et de donner un certain fil de développement pour venir à bout de la problématique posée.
Ce qui reviendra à proposer des axes/questions sur les manipulations de cette maquette de TP.

== Note valable pour toutes les semaines ==

'''[[Si un point vous semble imprécis, veuillez vous reportez aux détails fournit en annexe.]]'''

== 1éme semaine: (du 27/01/2014 au 01/02/2014) ==

Séance du 05/02/2014 :

Pour bien comprendre les différentes choses à réaliser, on a refait les manipulations vues en TP. On a, pour cela utiliser la maquette didactique TIMS pour générer différent type de modulation:

-la modulation en 4,8,16PSK (on obtient une constellation en forme de cercle).

-La modulation en 4,8,16QAM (on obtient une constellation avec un carré, ou deux: de différentes tailles).

On a très vite dégagé la nécessité de réaliser un montage générateur de tous les mots numériques possibles.
On a donc fait un programme sur arduino qui équivaut au générateur pseudo aléatoire.
Celui-ci est directement inspiré du montage que l'on a réalisé l'année dernière en conception de circuit électronique.

Séance du 06/02/2014 :

Lors de cette séance on a exploré toute les possibilités concernant la communication entre la maquette/carte car cela pour avoir une influecnce non négligeable sur le choix de la carte F.P.G.A. et du design de la maquette.

On a donc aussi fait des recherches concernant les possibilités de communications et les bloc I.P. (Intellectual Properties) permettant de programmer un F.P.G.A.

Et enfin, on a eu une discussion avec un responsable technique pour ce qui de la C.E.M. (Compatibilité Electro-Magnétique)

== 2éme semaine: (du 03/02/2014 au 08/02/2014) ==

Réflexion sur les possibilités possibles et offertes par le sujet pour ce qui est des parties de communications entre la maquette en interne et de son environnement.

[[Fichier:P34_2013_2014_schéma_principe_carte_semaine_2.PNG|300px|thumb|center|Maquette en interne/externe.]]

N'ayant jamais utilisé d'autre carte que la Nanoboard, on s'est attelé à faire des recherches sur la manière de procéder pour programmer une carte F.P.G.A., il se trouve que chaque carte de développement à ses propes manières pour être programmé.

On a pris le soin de notez toutes les questions concernant le F.P.G.A. pour un intervenant industrielle qui assura un cours la semaine prochaine.

== 3éme semaine: (du 10/02/2014 au 15/02/2014) ==

Ayant les oscillateurs commandables en tension, on a pu commencer à faire une manipulation avec les composants Mini Circuit.

Mais après un problème suite à une manipulation l'un des VCOs ne fonctionne plus.

Ce qui nous amène à penser qu'il sera judicieux de prévoir une alimentation au niveau de la carte.

Celle-ci devra être inférieure ou égale à la tension maximale d'alimentation du composant (ceux-ci étant très sensible).

Questions/Réponses:

Comment fait-on pour programmer une carte F.P.G.A. est-ce que la programmation se fait "in situe" ? (in situe : c'est à dire sur la carte elle même)
Oui, c'est ce qui est utilisé, via une câble JTAG.

Est-ce possible faire une interface USB pour permettre à un ordinateur de communiquer avec la maquette/carte via un F.P.G.A. ? Oui.

Est-ce que la gestion de l'interface Ethernet est envisageable ? Oui.

Pour une communication en protocole UDP avec un ordinateur via une liaison Ethernet, est-ce qu'il y a d'autre façon que d'utiliser un Soft Core ?

Oui, il existe aussi bien en Software, qu'en Hardware.

== 4éme semaine: (du 17/02/2014 au 22/02/2014) ==

On a donc repris l'idée de la 2éme semaine.

Après avoir mis en place un cahier des charges au niveau des qualités, bande passante minimale.

Nous avons fait des recherches sur les composants à utiliser (ie CAN, CAN, ...)

Ce qui nous a permis après une édition rapide de schéma électrique (schematic) d'avoir une idée du nombre de pins dont nous aurons besoin sur une carte FPGA afin de réaliser le projet.

Après prospection, il se trouve que nous nous dirigerions vers la carte Digilent Spartan 3, dont l'école était déjà en possession.

Donc nous nous sommes attelés à faire des recherches et des essais sur cette carte et pour notamment trouver un moyen de la faire fonctionner.

== 5éme semaine: (du 03/03/2014 au 08/03/2014) ==

Tout d'abord, après plusieurs heures de recherches et d'essai infructueux, on a fini par trouver les drivers pour le câble USB diligent.

Et donc ainsi avoir un fonctionnement de la communication via le câble JTAG plus propice au fonctionnement de la carte.

On a pu enfin se conforter sur une partie des composants et des dimensionnements pour certains d'entre eux (valeur de résistance,capacité...)

Schématics: Édition de multiple bibliothèque pour Altium, intégrant à la fois schématics et leur empreinte PCB associés.

(On a pu constater qu'un interface 3v3 5v n'est pas forcement nécessaire pour assurer le bon fonctionnement entre deux cartes avec des tensions d'alimentation différentes.)

== 6éme semaine: (du 10/03/2014 au 15/03/2014) ==

On a pu enfin se conforter sur l'ensemble des composants et des choix de régulateur et utilisation d'autre diode Zener.

On trouvera le schéma intégrale avec les bibliothèques nécessaires dans la semaine 5.

Cette semaine à été dédié à l'envoie de la commande des composants au sein du magasin de l'école et du fournisseur.

Après envoi de la commande, il se trouve que le projet a changé d'objectif principal.

Il est maintenant prioritaire de réaliser un code VHDL capable d'évaluer la vitesse de transmission numérique du côté récepteur.

== 7éme semaine: (du 17/03/2014 au 22/03/2014) ==

Pour cette semaine, on s'est concentré sur la réalisation d'un générateur pseudo aléatoire en interne au FPGA.

On réalisera une échelle de résistance afin de réaliser une conversion numérique analogique afin de l'envoyer sur la chaine de transmission.

Ce code de "base" nous permettra de réaliser un flux de données fictif pour obtenir toutes les combinaisons récupérant le résultat du bus.

[[MédiaP34_2013_2014_gene_pseudo_19_03_2014_6_semaine_7.zip|Archive contenant le projet ISE Xilinx.]]

[[Fichier:P34_2013_2014_rtl_semaine_7.PNG|300px|thumb|center|extrait du schéma RTL, on peut y voir clairement les inférences de Xilinx.]]

Ce schéma a deux entrées et une sortie, une entrée d'initialisation, une horloge et une sortie pour la trame en pseudo aléatoire.

On fera l'essaie sur la carte lors de la semaine suivante.

== 8éme semaine: (du 24/03/2014 au 26/03/2014) ==

Aprés le premier test, on pourrait penser que l'on récupère du bruit en sortie de la carte:

[[Fichier:P34_2013_2014_DSC_0024_1_probleme_d_overshoot_semaine_8.jpg|300px|thumb|center|Overshoot.]]

Pour pouvoir remédier à ce problème on a fait une pré-division de l'horloge

[[Fichier:P34_2013_2014_DSC_0037_1_div_freq_semaine_8.jpg|300px|thumb|center|Overshoot après division.]]

[[Fichier:P34_2013_2014_DSC_0039_1_div_freq_zoom_semaine_8.jpg|300px|thumb|center|Overshoot après division (Zoom).]]

Archive contenant toutes les modifications:

[[Média:P34_2013_2014_gene_pseudo_26_03_2014_2_semaine_8.zip|VHDL Semaine 8.]]

On a trouvé un moyen de faire un CNA facilement, via une "échelle dit R-2R". [[http://www.uchobby.com/index.php/2008/01/08/arduino-audio-dac-options/|Pour le réseau R 2R.]]

Il faut encore modifier le VHDL pour pouvoir l'exploiter et ainsi générer une constellation.

== 9éme semaine: (du 28/03/2014 au 03/04/2014) ==

On a pris donc le soin de modifier le VHDL:

[[Média:P34_2013_2014_gene_pseudo_31_03_2014_1_semaine_9.zip|VHDL semaine 9]]

Ce VHDL à été mis à jour, avec deux entrées (initialisation et une horloge) et un bus de sortie (8 bits), avec les trames pseudo-aléatoire.

On envoie ces signaux sur deux C.N.A.s (4 bits chacun) pour générer deux signaux I et Q, on peut voir une constellation se dessiner en mode X-Y.

[[Fichier:P34_2013_2014_DSC_0072_1_Montage_entier_4qam_semaine_9.jpg|300px|thumb|center|Montage avec constellations 4QAM.]]

D'autre constellations réalisées sont disponibles en annexe. On peut monter jusqu'à une constellation de 256 points (2^4*2^4).

On a réalisé le montage complet de toute la chaine de transmission. Il se trouve que la Boucle à Verrouillage de Phase (ou appellée PLL, Phase Loop Locker) ne se verrouille pas sur la porteuse du signal que l'on souhaite récupéré, de ce fait on ne peut pas récupérer les signaux I et Q.

== 10éme semaine: (du 07/04/2014 au 10/04/2014) ==

On a réalisé le montage que l'on évoqué en semaine 9:

P34_2013_2014_DSC_0027_montage_realisee_semaine_10.jpg

[[Fichier:P34_2013_2014_DSC_0027_montage_realisee_semaine_10.jpg|center|thumb|300px|Montage pour amélioré la PLL.]]

Il se trouve qu’après un réglage précis de la tension d'offset permettant d'être un proche de la fréquence à capturé on obtient:

[[Fichier:P34_2013_2014_DSC_0025_PLL_non_verrouillage_semaine_10.jpg|center|thumb|300px|Signaux I/Q après ajout du montage.]]

= Annexes =

== Annexe A: Détails techniques des semaines ==

=== 1éme semaine: (du 27/01/2014 au 01/02/2014) ===

Après on a réfléchi sur la potentielle conception/utilisation d'une carte FPGA.
Il sera judicieux de ne pas se précipiter sur le schéma et la conception/utilisation d'une carte FPGA, sans avoir, au préalable fait le VHDL et le testez avec un banc de test virtuel.
L'intérêt et de mettre en valeur la nécessité ou non de certains signaux pour le schéma de la carte.
On va mettre en oeuvre les connaissances acquises au S7 en VHDL (en TP de Circuit Numérique Programmble).

Pour ce qui est de l'Arduino, on a répondu aux interrogations suivantes (certaines de ces questions paraissent triviales, mais on préfère éviter les surprises):

Quelle est la vitesse maximale de la communication série de l'Arduino ?
-115200bauds

Est-ce que, un programme de type "Analog Write" est-il une vraie sortie analogique ?

-Non, c'est juste une PWM. Elle sera exploitable pour faire les signales I/Q mais très contraignantes, car il faudra filtré le signal, et ce sera beaucoup trop lent (du au fait que la modulation est faite au alentour de 850Mhz), le FPGA sera un passage obligé cela ouvrira les portes d'un plus grand débit.

==== Manipulation réalisée sur la maquette TIMS : ====

On a fait un des montages présenté dans l'ouvrage "Volume D1 Fundamental Digital Experiments" dans le but de visualiser l’objectif à atteindre.

On obtient la constellation suivante (16QAM):

[[Fichier:P34_2013_2014_constelation_tims_semaine_1.PNG|300px|thumb|center|Constellation visualisé en mode X-Y.]]

Ce qui correspond à deux signaux en visualisation temporelle de cette forme :

[[Fichier:P34_2013_2014_constelation_temporelle_tims_semaine_1.PNG|300px|thumb|center|Signaux I et Q. (Image très flouté, à remplacer)]]

On pourra facilement obtenir le même résultat en générant un bus de trame pseudo aléatoire et en l'injectant dans un C.N.A. (Conversion Numérique Analogique)

==== Code Arduino réalisé: ====

[[Fichier:P34_2013_2014_schema_electronique_generateur_pseudo_aleatoire.png|300px|thumb|center|Schéma électronique du générateur pseudo aléatoire.]]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_chrono_simule.PNG|300px|thumb|center|Résultat de la simulation du générateur pseudo aléatoire (on a eu la même chose en pratique).]]

[code]
/*A peut être supprimer*/
#include <avr/io.h>
#include <util/delay.h>

void output_init(void){
DDRB |= 0x02; // PIN 8,9 sont les deux sorties.
}

int main(void){
int r1=1,r2=0,r3=0,r4=0,r5=0,retard=0;
PORTB=0x00;
while(1)
{
r5=r4;//chaque affectation représente une recopie de la bascule sur le "front montant", ici c'est simplement l’exécution du code.
r4=r3;
r3=r2;
r2=r1;
r1=r4^r5;
PORTB=0x01*r1+0x02*retard;//écriture des signaux
_delay_ms(10);//le "front montant", ce qui permet de faire un genre d'horloge.
retard=r5;//déphasage du signal
}
return 0;
}
[/code]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_arduino.jpg|300px|thumb|center|Resultat avec le generateur pseudo aléatoire "émuler" avec l'Arduino.]]

Comparaison carte réelle/résultat Arduino:

C'était exactement les signaux attendus (même s'il y un décalage a par rapport à l'original).

On aura bien pour une QPSK (4PSK) tous les couples (ie 00,01,11 et 10).

À propos de l'arduino, on pourra envisager une amélioration pour générer une séquence plus longue:

-il faudra simplement utiliser un tableau d'entier.

-paramétrer sa taille avec un N par exemple.

-N correspondra à la taille de séquence de longueur 2^N.

Voir la section "Code Arduino réalisé" en annexe B dans la semaine correspondante.

==== Possibilités de communications: ====

Exploration des possibilités de communication entre le PC et la carte en amont:

=====-> Ethernet: =====

*+ Vitesse de transmission (~10M-100M-G)bauds

*- La gestion du flux de données doit être faite par un microcontrôleur (celui-ci pourra être implémenté un bloc I.P. à l'intérieur du FPGA)

-> - Haute consommation de CLB du FPGA.

=====-> SPI (communication série): =====

*- Vitesse de transmission

-> Arduino capable de communiquer jusqu'a 115200 bauds

-> D'après certaines discussions on pourrait « pousser » au-delà : voir le lien des sujets Raspberry Pi.

=====-> I2C : =====

Communication abandonné, ce n'est pas une priorité.

==== À propos des blocs I.P.: ====

En consultant les ordinateurs et en s'appuyant des TPs de CNP, on constate que les blocs suivants existent:

- Xilinx Microblaze/Xilinx Power PC ("µP FPGA")

-> Est-ce possible d'utiliser ces blocs I.P. pour programmer un FPGA sur une carte autre que la Nanoboard ? Comment ?

- EMACx (Ethernet Media Acess Control)(:lien physique entre processeurs et "standart Physical Layer device IEEE802.3")

===== Conception de la carte: =====

L'idéal est de se documenter sur la Compatibilité électromagnétique.

=== 2éme semaine: (du 03/02/2014 au 08/02/2014) ===

(Rien en annexe.)

=== 3éme semaine: (du 10/02/2014 au 15/02/2014) ===

Lors de cette semaine, après avoir eu le problème de manipulation, nous avons pus prendre connaissance d'un certain montage qui s’avéra utile pour la conception de la carte/maquette.

[[Fichier:P34_2013_2014_schéma_limiteur_de_courant_semaine_3.PNG|300px|thumb|center|Schéma limiteur de courant.]]

On remarquera que ce montage se retrouve dans la partie "typical application" de la documentation technique du 7805.

=== 4éme semaine: (du 17/02/2014 au 22/02/2014) ===

On souhaite pouvoir réaliser une communication unidirectionnel ou même transmettre un signal audio ce qui nous contraint à une bande passante minimal de 48kHz, on prendra 200kHz (Pour être bien au delà de la conditions du théorème de Shannon): le but serait donc de branchez par exemple une source audio quelconque puis de la transmettre à travers la maquette et de la recomposer en fin de chaine.

Après édition rapide du schématique on en dégage qu'il nous faudra un minimum d'environ 50 entrées/sorties. Mais ceci ce nombre sera très probablement revue à la hausse lors de prochaine séance.

Voici la carte que l'on utilisera dans la suite du projet:

[[Fichier:P34_2013_2014_S3BOARD-top-400_semaine_4.gif|300px|thumb|center|Digilent Spartan 3.]]

=== 5éme semaine: (du 03/03/2014 au 08/03/2014) ===

Lien vers le Design complet avec les librairies incluses (on remarquera qu'il serait judicieux d’installer toutes les librairies avant d’essayer d'ouvrir le schéma)

A notez aussi que l'on trouvera des reliques de feuilles Excel permettant de trouver rapidement des ratios dans la série E12.

[[Média:P34_2013_2014_Design_pcb_plus_librairies_semaine_5_6.zip|Schéma + Bibliothèques.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.pdf|Schéma en PDF.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.png|Schéma au format A2.]]

=== 6éme semaine: (du 10/03/2014 au 15/03/2014) ===

(Rien en annexe.)

=== 7éme semaine: (du 17/03/2014 au 22/03/2014) ===

(Rien en annexe.)

=== 8éme semaine: (du 24/03/2014 au 26/03/2014) ===

(Rien en annexe.)

=== 9éme semaine: (du 28/03/2014 au 03/04/2014) ===

[[Fichier:P34_2013_2014_DSC_0061_1_r_2r_semaine_9.jpg|center|thumb|300px|Le réseau R-2R.]]

[[Fichier:P34_2013_2014_DSC_0062_1_4QAM_semaine_9.jpg|center|thumb|300px|4QAM.]]

[[Fichier:P34_2013_2014_DSC_0066_1_16QAM_semaine_9.jpg|center|thumb|300px|16QAM.]]

[[Fichier:P34_2013_2014_DSC_0069_1_64QAM_semaine_9.jpg|center|thumb|300px|64QAM.]]

Pas de photos pour la constellation à 256 points, mais elle a été réalisée.

Pour ce qui est du montage, malgré que la P.L.L., on a un signal d'erreur après filtrage :

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Chaine 1: Vtune (commande du V.C.O.)/Chaine 2: "erreur" de commande]]

Ce qui mets en valeur immédiatement deux problèmes majeurs:

La chaine fonctionne sur le papier, mais lors de sa mise en pratique, il faut penser à mettre une tension d'offset et aussi réaliser une amplification de l'erreur pour avoir des grandeur de commande adapté au Vtune du V.C.O..

On propose l'amélioration suivante (qui sera réalisé à la prochaine séance):

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Proposition de voie d'amélioration.]]

On remarquera que les valeurs des résistances et des capacité on était choisit pour permettre un fonctionnement correct des A.O. (Amplificateur Opérationnel), mais pas pour ce qui de l'asservissement de la boucle par manque de temps.

A la fin de cette, on a eu à démonter le montage à cause de contraintes concernant les mini-circuits (car utilisé en travaux pratiques).

=== 10éme semaine: (rédaction en cours) (du 07/04/2014 au 10/04/2014) ===

Spectres des signaux de la chaine de transmission:

[[Fichier:P34_2013_2014_DSC_0001_allure_spectre_reception_semaine_10.jpg|center|thumb|300px|Spectre en réception.]]

Porteuse utilisé pour la modulation I/Q à environ 60MHz.

P34_2013_2014_DSC_0001_allure_spectre_reception_semaine_10.jpg

Porteuse utilisé pour le transport en fréquence à environ 810MHz:

[[Fichier:P34_2013_2014_DSC_0035_constellation_recupere_PLL_NV_semaine_10.jpg|center|thumb|300px|"Constellation" récupéré avec la PLL défectueuse (on souhaite se verrouillé sur la raie à 868MHz).]]

Question en suspend: faudrai t'il utiliser un filtre passe bande incluant 868Mhz pour pouvoir se verrouillé sur cette fréquence ?

On remarquera sur le fait que l'oscillateur du côté de la chaine d'émission à d'importante non linéarité (on peut observer à l'analyseur de spectre 3 à 4 raies aux fréquences multiples).

Ce qui donne un diagramme de constellation plutôt mauvais si l'on fait le montage suivant:

[[Fichier:P34_2013_2014_montage_non_linearite_vco_constellation_semaine_10.PNG|center|thumb|300px|Montage réalisée.]]

[[Fichier:P34_2013_2014_sortie_montage_non_linearite_semaine_10.PNG|center|thumb|300px|La constellation 4QAM est attendu, on est loin du résultat attendu (Aucune photo n'a était réalisé d'ou le dessin).]]

== Annexe B: Digilent Spartan 3 ==

=== Procédure pour faire fonctionner la carte Digilent Spartan 3: ===

Ne connectez pas de connecteur JTAG pendant les installations. Redémarrez après chaque installation.

Tout d'abord, il faut savoir que le l'ISE Webpack 14.6 fonctionne avec la carte (n'utilisez pas la 14.7, elle ne supporte pas la génération spartan 3 !):

Installez donc l'ISE WebPack 14.6 (ou antérieur à condition que celle-ci soit supérieur à la 7.1i (d'aprés leur documentation))

(voir lien utile sur Xilinx)

Une fois l'installation de l'ISE terminé, faites en sorte d'avoir celui que soit opérationnel (la licence est gratuite !).

Installez la "library" ADEPT 2.3 voir le lien utile.

Après vous n'avez plus qu'a utilisez ISE Xilinx normalement et vous serez capable de reconnaitre la carte via la liaison JTAG, et de le programmer.

=== Liens utiles: ===

Lien constructeur/vendeur (avec ressources utiles en bas de la page):

http://www.digilentinc.com/Products/Detail.cfm?Prod=S3BOARD

Lien "Library" pour le câble USB digilent:

http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,66,69&Prod=ADEPT

Lien Xilinx (Pour l'ISE 14.6):

http://www.xilinx.com/products/design-tools/ise-design-suite/index.htm

Lien Xilinx (Pour les versions antérieures veuillez faire attention au système d'exploitation, votre architecture matérielle et le FPGA cible):

(Les informations de compatibilité son sur la page suivante:) (mots clés: xilinx classic(s))

http://www.xilinx.com/tools/classics.htm

=== Procédure pour faire une programmation en volatile: ===

Générer le bitstream, et le charger.

=== Procédure pour faire une programmation en "non"-volatile: ===

Générer le bitstream et l'utiliser pour générer un .mcs qui vous permettra d'inscrire le programme dans la mémoire (E?)PROM.

On remarquera que la programmation en non-volatile est utile pour faire un remise à zéro et recharger le contenu de l'(E?)PROM, mais semble être sensible au débranchement de l'adaptateur d'alimentation de la carte.

=== Exemple de programmation: ===

Voir le lien digilent pour ceci dans cette annexe.

Fichier:P34 2013 2014 sortie montage non linearite semaine 10.PNG

2014-04-13T20:40:52Z

Jvaessen :

Fichier:P34 2013 2014 montage non linearite vco constellation semaine 10.PNG

2014-04-13T20:28:25Z

Jvaessen :

Fichier:P34 2013 2014 Chaine modulation.PNG

2014-04-13T20:25:07Z

Jvaessen : a téléversé une nouvelle version de « Fichier:P34 2013 2014 Chaine modulation.PNG »

Partie modulation.

Modem pour le numérique

2014-04-13T20:19:28Z

Jvaessen : /* 10éme semaine: (rédaction en cours) (du 07/04/2014 au 10/04/2014) */

= Modulateur et démodulateur pour communications numériques =

== Cahier des charges ==

=== Présentation générale du projet ===

Dans le cadre des TPs d'électronique et de transmission RF, nous avons découvert qu'il existe plusieurs modes de modulation, pour transmettre un signal modulant.

Celles vues en TP au S7 sont la modulation en amplitude, en fréquence, en phase, en BPSK et en QPSK.

Or les modulations en phase, en fréquence et en amplitude étant celles les plus connues, la modulation en QAM (Modulation d'Amplitude en Quadrature) est quant à elle moins connue, mais tout aussi utilisées:

-pour la TNT en 64 QAM (en France).

[[Fichier:P34_2013_2014_64qam.jpg|300px|thumb|center|Exemple de constellation 64QAM.]]

-pour le WiFi en 64-QAM ou 256-QAM (à vérifier).

Or ces deux dernières étant peu représentées au niveau des travaux pratiques, ce projet permettra de fournir un peu plus de pratique sur les modulations de type QAM (en diagramme I/Q) dans le domaine des radiofréquences (~800MHz).

(Le nombre devant le QAM indique le nombre de points dans le diagramme I/Q qu'on appelle aussi constellation)

On se réserve le droit de faire '''évoluer''' le cahier des charges a posteriori, si certaines contraintes étaient amenées à évoluer ou se préciser.

=== Objectif et intérêt du projet ===

Pour cela, on nous a fourni des modules commerciaux Mini-circuit pouvant travailler dans les radios-fréquences.

Ceux-ci permettront de mettre en place une grande partie de la chaine de transmission (voir schéma de la chaine de transmission).

[[Fichier:P34_2013_2014_Chaine_modulation.PNG|300px|thumb|center|Modulation.]]

[[Fichier:P34_2013_2014_Chaine_demodulation.PNG|300px|thumb|center|Demodulation.]]

On a tout d'abord à mettre en place une carte FPGA et/ou un dispositif permettant d'envoyer un flux de données numériques continuellement pour pouvoir visualiser le diagramme I/Q (mise en valeur du diagramme I/Q et voir même un diagramme un peu plus complexe que le BPSK ou le QPSK).

Le canal de transmission qui sera un simple fil électrique, mais pourra devenir une antenne réceptrice et émettrice si le temps imparti le permet (mise en valeur du et mesure du Bit Error Rate qui sera bien sûr différent suivant le canal de transmission).

Du côté réception ,après démodulation du signal, une remise en forme et une interprétation des données seront réalisées, celle-ci dépendra bien entendu de la provenance du flux de données (constater le succès ou l'échec d'un envoi de données).

Enfin si le temps le permets on pourra mettre en une place un système de codage de l'information avec par exemple un codage redondant permettant de corrigé l'erreur (À définir, on pourra faire constater l'efficacité d'une méthode de codage au choix).

=== Étapes/Déroulement du projet ===

De même que pour le cahier des charges, il se peut que les étapes diffèrent plus ou moins, en fonction des disponibilités, matérielles et contraintes.

==== => Caractérisation des blocs Mini-circuits et épluchage des documentations techniques====
Avant de les utiliser dans la chaine de transmission, nous avons à faire une caractérisation des blocs fournis:

-la caractérisation du VCO.

-l'étude des possibilités offerte par le modulateur (cela déterminera le nombre de points possible dans la constellation, ie savoir si l'on peut aller au-delà de la QPSK).

-la caractérisation des mélangeurs (Mixer), leurs facteurs réels de multiplication.

==== => Utilisation et exploitation des caractérisations ====
On pourra ensuite trouver les paramètres pour régler correctement dans notre chaine de transmission certains de nos sous-systèmes comme la boucle à verrouillage de phase.

==== => Génération d'un flux des données numériques ====
Comme dit précédemment, l'idéal et d'avoir un flux de données numériques transmis en permanence.
Pour cela plusieurs solutions s'offre à nous, on pourra utiliser un montage générateur pseudo aléatoire (un circuit que l'on a fait l'année dernière en Conception de Circuit Électronique).
On pourra "émuler" ce montage avec un Arduino, ou bien même le faire au moyen de la Nanoboard.
On pourra aussi transmettre des chaines de caractère en continu.

==== => Test de la chaine ====
Une fois les étapes précédentes réalisées, on pourra passer au test de la chaine de transmission. Il faudra vérifier le bon fonctionnement en aval, dedans (boucle a verrouillage de phase), et en amont de la chaine de transmission.

==== => Première mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.
Il est possible que la conception d'un dispositif soit nécessaire que ce soit pour les deux mesures du B.E.R..

==== => Antennes ====
Si toutes les étapes précédentes sont satisfaites, on pourra alors faire un canal de transmission plus intéressant, à savoir l'air.
Nous passerons alors à la conception des antennes, émettrice et réceptrice.

==== => Deuxième mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.

==== => Codage de l'information et correction d'erreur ====
En toute fin de ce projet, on pourra même mettre deux dispositifs en aval et en amont de la chaine de transmission.
On réalisera alors un codeur et un décodeur permettant de faire de la détection/correction d'erreur.

==== => Mise en place d'outil de débogage (tout au long)====
La mise en place de simples outils de débogage et primordiale, ceux-ci permettront de vérifier le bon fonctionnement de la chaine.

==== => Proposition d'un sujet de TP (tout au long) ====
Il se trouve que lors du déroulement du projet, on pourra être amené à se poser des questions au niveau des réglages de la chaine de transmission.
Or il est fort probable que les élèves qui travailleront sur ce TP pourront alors se poser les mêmes questions.
C'est pour cela qui sera judicieux de prendre soin de noter les problématiques rencontrées et de donner un certain fil de développement pour venir à bout de la problématique posée.
Ce qui reviendra à proposer des axes/questions sur les manipulations de cette maquette de TP.

== Note valable pour toutes les semaines ==

'''[[Si un point vous semble imprécis, veuillez vous reportez aux détails fournit en annexe.]]'''

== 1éme semaine: (du 27/01/2014 au 01/02/2014) ==

Séance du 05/02/2014 :

Pour bien comprendre les différentes choses à réaliser, on a refait les manipulations vues en TP. On a, pour cela utiliser la maquette didactique TIMS pour générer différent type de modulation:

-la modulation en 4,8,16PSK (on obtient une constellation en forme de cercle).

-La modulation en 4,8,16QAM (on obtient une constellation avec un carré, ou deux: de différentes tailles).

On a très vite dégagé la nécessité de réaliser un montage générateur de tous les mots numériques possibles.
On a donc fait un programme sur arduino qui équivaut au générateur pseudo aléatoire.
Celui-ci est directement inspiré du montage que l'on a réalisé l'année dernière en conception de circuit électronique.

Séance du 06/02/2014 :

Lors de cette séance on a exploré toute les possibilités concernant la communication entre la maquette/carte car cela pour avoir une influecnce non négligeable sur le choix de la carte F.P.G.A. et du design de la maquette.

On a donc aussi fait des recherches concernant les possibilités de communications et les bloc I.P. (Intellectual Properties) permettant de programmer un F.P.G.A.

Et enfin, on a eu une discussion avec un responsable technique pour ce qui de la C.E.M. (Compatibilité Electro-Magnétique)

== 2éme semaine: (du 03/02/2014 au 08/02/2014) ==

Réflexion sur les possibilités possibles et offertes par le sujet pour ce qui est des parties de communications entre la maquette en interne et de son environnement.

[[Fichier:P34_2013_2014_schéma_principe_carte_semaine_2.PNG|300px|thumb|center|Maquette en interne/externe.]]

N'ayant jamais utilisé d'autre carte que la Nanoboard, on s'est attelé à faire des recherches sur la manière de procéder pour programmer une carte F.P.G.A., il se trouve que chaque carte de développement à ses propes manières pour être programmé.

On a pris le soin de notez toutes les questions concernant le F.P.G.A. pour un intervenant industrielle qui assura un cours la semaine prochaine.

== 3éme semaine: (du 10/02/2014 au 15/02/2014) ==

Ayant les oscillateurs commandables en tension, on a pu commencer à faire une manipulation avec les composants Mini Circuit.

Mais après un problème suite à une manipulation l'un des VCOs ne fonctionne plus.

Ce qui nous amène à penser qu'il sera judicieux de prévoir une alimentation au niveau de la carte.

Celle-ci devra être inférieure ou égale à la tension maximale d'alimentation du composant (ceux-ci étant très sensible).

Questions/Réponses:

Comment fait-on pour programmer une carte F.P.G.A. est-ce que la programmation se fait "in situe" ? (in situe : c'est à dire sur la carte elle même)
Oui, c'est ce qui est utilisé, via une câble JTAG.

Est-ce possible faire une interface USB pour permettre à un ordinateur de communiquer avec la maquette/carte via un F.P.G.A. ? Oui.

Est-ce que la gestion de l'interface Ethernet est envisageable ? Oui.

Pour une communication en protocole UDP avec un ordinateur via une liaison Ethernet, est-ce qu'il y a d'autre façon que d'utiliser un Soft Core ?

Oui, il existe aussi bien en Software, qu'en Hardware.

== 4éme semaine: (du 17/02/2014 au 22/02/2014) ==

On a donc repris l'idée de la 2éme semaine.

Après avoir mis en place un cahier des charges au niveau des qualités, bande passante minimale.

Nous avons fait des recherches sur les composants à utiliser (ie CAN, CAN, ...)

Ce qui nous a permis après une édition rapide de schéma électrique (schematic) d'avoir une idée du nombre de pins dont nous aurons besoin sur une carte FPGA afin de réaliser le projet.

Après prospection, il se trouve que nous nous dirigerions vers la carte Digilent Spartan 3, dont l'école était déjà en possession.

Donc nous nous sommes attelés à faire des recherches et des essais sur cette carte et pour notamment trouver un moyen de la faire fonctionner.

== 5éme semaine: (du 03/03/2014 au 08/03/2014) ==

Tout d'abord, après plusieurs heures de recherches et d'essai infructueux, on a fini par trouver les drivers pour le câble USB diligent.

Et donc ainsi avoir un fonctionnement de la communication via le câble JTAG plus propice au fonctionnement de la carte.

On a pu enfin se conforter sur une partie des composants et des dimensionnements pour certains d'entre eux (valeur de résistance,capacité...)

Schématics: Édition de multiple bibliothèque pour Altium, intégrant à la fois schématics et leur empreinte PCB associés.

(On a pu constater qu'un interface 3v3 5v n'est pas forcement nécessaire pour assurer le bon fonctionnement entre deux cartes avec des tensions d'alimentation différentes.)

== 6éme semaine: (du 10/03/2014 au 15/03/2014) ==

On a pu enfin se conforter sur l'ensemble des composants et des choix de régulateur et utilisation d'autre diode Zener.

On trouvera le schéma intégrale avec les bibliothèques nécessaires dans la semaine 5.

Cette semaine à été dédié à l'envoie de la commande des composants au sein du magasin de l'école et du fournisseur.

Après envoi de la commande, il se trouve que le projet a changé d'objectif principal.

Il est maintenant prioritaire de réaliser un code VHDL capable d'évaluer la vitesse de transmission numérique du côté récepteur.

== 7éme semaine: (du 17/03/2014 au 22/03/2014) ==

Pour cette semaine, on s'est concentré sur la réalisation d'un générateur pseudo aléatoire en interne au FPGA.

On réalisera une échelle de résistance afin de réaliser une conversion numérique analogique afin de l'envoyer sur la chaine de transmission.

Ce code de "base" nous permettra de réaliser un flux de données fictif pour obtenir toutes les combinaisons récupérant le résultat du bus.

[[MédiaP34_2013_2014_gene_pseudo_19_03_2014_6_semaine_7.zip|Archive contenant le projet ISE Xilinx.]]

[[Fichier:P34_2013_2014_rtl_semaine_7.PNG|300px|thumb|center|extrait du schéma RTL, on peut y voir clairement les inférences de Xilinx.]]

Ce schéma a deux entrées et une sortie, une entrée d'initialisation, une horloge et une sortie pour la trame en pseudo aléatoire.

On fera l'essaie sur la carte lors de la semaine suivante.

== 8éme semaine: (du 24/03/2014 au 26/03/2014) ==

Aprés le premier test, on pourrait penser que l'on récupère du bruit en sortie de la carte:

[[Fichier:P34_2013_2014_DSC_0024_1_probleme_d_overshoot_semaine_8.jpg|300px|thumb|center|Overshoot.]]

Pour pouvoir remédier à ce problème on a fait une pré-division de l'horloge

[[Fichier:P34_2013_2014_DSC_0037_1_div_freq_semaine_8.jpg|300px|thumb|center|Overshoot après division.]]

[[Fichier:P34_2013_2014_DSC_0039_1_div_freq_zoom_semaine_8.jpg|300px|thumb|center|Overshoot après division (Zoom).]]

Archive contenant toutes les modifications:

[[Média:P34_2013_2014_gene_pseudo_26_03_2014_2_semaine_8.zip|VHDL Semaine 8.]]

On a trouvé un moyen de faire un CNA facilement, via une "échelle dit R-2R". [[http://www.uchobby.com/index.php/2008/01/08/arduino-audio-dac-options/|Pour le réseau R 2R.]]

Il faut encore modifier le VHDL pour pouvoir l'exploiter et ainsi générer une constellation.

== 9éme semaine: (du 28/03/2014 au 03/04/2014) ==

On a pris donc le soin de modifier le VHDL:

[[Média:P34_2013_2014_gene_pseudo_31_03_2014_1_semaine_9.zip|VHDL semaine 9]]

Ce VHDL à été mis à jour, avec deux entrées (initialisation et une horloge) et un bus de sortie (8 bits), avec les trames pseudo-aléatoire.

On envoie ces signaux sur deux C.N.A.s (4 bits chacun) pour générer deux signaux I et Q, on peut voir une constellation se dessiner en mode X-Y.

[[Fichier:P34_2013_2014_DSC_0072_1_Montage_entier_4qam_semaine_9.jpg|300px|thumb|center|Montage avec constellations 4QAM.]]

D'autre constellations réalisées sont disponibles en annexe. On peut monter jusqu'à une constellation de 256 points (2^4*2^4).

On a réalisé le montage complet de toute la chaine de transmission. Il se trouve que la Boucle à Verrouillage de Phase (ou appellée PLL, Phase Loop Locker) ne se verrouille pas sur la porteuse du signal que l'on souhaite récupéré, de ce fait on ne peut pas récupérer les signaux I et Q.

== 10éme semaine: (du 07/04/2014 au 10/04/2014) ==

On a réalisé le montage que l'on évoqué en semaine 9:

P34_2013_2014_DSC_0027_montage_realisee_semaine_10.jpg

[[Fichier:P34_2013_2014_DSC_0027_montage_realisee_semaine_10.jpg|center|thumb|300px|Montage pour amélioré la PLL.]]

Il se trouve qu’après un réglage précis de la tension d'offset permettant d'être un proche de la fréquence à capturé on obtient:

[[Fichier:P34_2013_2014_DSC_0025_PLL_non_verrouillage_semaine_10.jpg|center|thumb|300px|Signaux I/Q après ajout du montage.]]

= Annexes =

== Annexe A: Détails techniques des semaines ==

=== 1éme semaine: (du 27/01/2014 au 01/02/2014) ===

Après on a réfléchi sur la potentielle conception/utilisation d'une carte FPGA.
Il sera judicieux de ne pas se précipiter sur le schéma et la conception/utilisation d'une carte FPGA, sans avoir, au préalable fait le VHDL et le testez avec un banc de test virtuel.
L'intérêt et de mettre en valeur la nécessité ou non de certains signaux pour le schéma de la carte.
On va mettre en oeuvre les connaissances acquises au S7 en VHDL (en TP de Circuit Numérique Programmble).

Pour ce qui est de l'Arduino, on a répondu aux interrogations suivantes (certaines de ces questions paraissent triviales, mais on préfère éviter les surprises):

Quelle est la vitesse maximale de la communication série de l'Arduino ?
-115200bauds

Est-ce que, un programme de type "Analog Write" est-il une vraie sortie analogique ?

-Non, c'est juste une PWM. Elle sera exploitable pour faire les signales I/Q mais très contraignantes, car il faudra filtré le signal, et ce sera beaucoup trop lent (du au fait que la modulation est faite au alentour de 850Mhz), le FPGA sera un passage obligé cela ouvrira les portes d'un plus grand débit.

==== Manipulation réalisée sur la maquette TIMS : ====

On a fait un des montages présenté dans l'ouvrage "Volume D1 Fundamental Digital Experiments" dans le but de visualiser l’objectif à atteindre.

On obtient la constellation suivante (16QAM):

[[Fichier:P34_2013_2014_constelation_tims_semaine_1.PNG|300px|thumb|center|Constellation visualisé en mode X-Y.]]

Ce qui correspond à deux signaux en visualisation temporelle de cette forme :

[[Fichier:P34_2013_2014_constelation_temporelle_tims_semaine_1.PNG|300px|thumb|center|Signaux I et Q. (Image très flouté, à remplacer)]]

On pourra facilement obtenir le même résultat en générant un bus de trame pseudo aléatoire et en l'injectant dans un C.N.A. (Conversion Numérique Analogique)

==== Code Arduino réalisé: ====

[[Fichier:P34_2013_2014_schema_electronique_generateur_pseudo_aleatoire.png|300px|thumb|center|Schéma électronique du générateur pseudo aléatoire.]]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_chrono_simule.PNG|300px|thumb|center|Résultat de la simulation du générateur pseudo aléatoire (on a eu la même chose en pratique).]]

[code]
/*A peut être supprimer*/
#include <avr/io.h>
#include <util/delay.h>

void output_init(void){
DDRB |= 0x02; // PIN 8,9 sont les deux sorties.
}

int main(void){
int r1=1,r2=0,r3=0,r4=0,r5=0,retard=0;
PORTB=0x00;
while(1)
{
r5=r4;//chaque affectation représente une recopie de la bascule sur le "front montant", ici c'est simplement l’exécution du code.
r4=r3;
r3=r2;
r2=r1;
r1=r4^r5;
PORTB=0x01*r1+0x02*retard;//écriture des signaux
_delay_ms(10);//le "front montant", ce qui permet de faire un genre d'horloge.
retard=r5;//déphasage du signal
}
return 0;
}
[/code]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_arduino.jpg|300px|thumb|center|Resultat avec le generateur pseudo aléatoire "émuler" avec l'Arduino.]]

Comparaison carte réelle/résultat Arduino:

C'était exactement les signaux attendus (même s'il y un décalage a par rapport à l'original).

On aura bien pour une QPSK (4PSK) tous les couples (ie 00,01,11 et 10).

À propos de l'arduino, on pourra envisager une amélioration pour générer une séquence plus longue:

-il faudra simplement utiliser un tableau d'entier.

-paramétrer sa taille avec un N par exemple.

-N correspondra à la taille de séquence de longueur 2^N.

Voir la section "Code Arduino réalisé" en annexe B dans la semaine correspondante.

==== Possibilités de communications: ====

Exploration des possibilités de communication entre le PC et la carte en amont:

=====-> Ethernet: =====

*+ Vitesse de transmission (~10M-100M-G)bauds

*- La gestion du flux de données doit être faite par un microcontrôleur (celui-ci pourra être implémenté un bloc I.P. à l'intérieur du FPGA)

-> - Haute consommation de CLB du FPGA.

=====-> SPI (communication série): =====

*- Vitesse de transmission

-> Arduino capable de communiquer jusqu'a 115200 bauds

-> D'après certaines discussions on pourrait « pousser » au-delà : voir le lien des sujets Raspberry Pi.

=====-> I2C : =====

Communication abandonné, ce n'est pas une priorité.

==== À propos des blocs I.P.: ====

En consultant les ordinateurs et en s'appuyant des TPs de CNP, on constate que les blocs suivants existent:

- Xilinx Microblaze/Xilinx Power PC ("µP FPGA")

-> Est-ce possible d'utiliser ces blocs I.P. pour programmer un FPGA sur une carte autre que la Nanoboard ? Comment ?

- EMACx (Ethernet Media Acess Control)(:lien physique entre processeurs et "standart Physical Layer device IEEE802.3")

===== Conception de la carte: =====

L'idéal est de se documenter sur la Compatibilité électromagnétique.

=== 2éme semaine: (du 03/02/2014 au 08/02/2014) ===

(Rien en annexe.)

=== 3éme semaine: (du 10/02/2014 au 15/02/2014) ===

Lors de cette semaine, après avoir eu le problème de manipulation, nous avons pus prendre connaissance d'un certain montage qui s’avéra utile pour la conception de la carte/maquette.

[[Fichier:P34_2013_2014_schéma_limiteur_de_courant_semaine_3.PNG|300px|thumb|center|Schéma limiteur de courant.]]

On remarquera que ce montage se retrouve dans la partie "typical application" de la documentation technique du 7805.

=== 4éme semaine: (du 17/02/2014 au 22/02/2014) ===

On souhaite pouvoir réaliser une communication unidirectionnel ou même transmettre un signal audio ce qui nous contraint à une bande passante minimal de 48kHz, on prendra 200kHz (Pour être bien au delà de la conditions du théorème de Shannon): le but serait donc de branchez par exemple une source audio quelconque puis de la transmettre à travers la maquette et de la recomposer en fin de chaine.

Après édition rapide du schématique on en dégage qu'il nous faudra un minimum d'environ 50 entrées/sorties. Mais ceci ce nombre sera très probablement revue à la hausse lors de prochaine séance.

Voici la carte que l'on utilisera dans la suite du projet:

[[Fichier:P34_2013_2014_S3BOARD-top-400_semaine_4.gif|300px|thumb|center|Digilent Spartan 3.]]

=== 5éme semaine: (du 03/03/2014 au 08/03/2014) ===

Lien vers le Design complet avec les librairies incluses (on remarquera qu'il serait judicieux d’installer toutes les librairies avant d’essayer d'ouvrir le schéma)

A notez aussi que l'on trouvera des reliques de feuilles Excel permettant de trouver rapidement des ratios dans la série E12.

[[Média:P34_2013_2014_Design_pcb_plus_librairies_semaine_5_6.zip|Schéma + Bibliothèques.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.pdf|Schéma en PDF.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.png|Schéma au format A2.]]

=== 6éme semaine: (du 10/03/2014 au 15/03/2014) ===

(Rien en annexe.)

=== 7éme semaine: (du 17/03/2014 au 22/03/2014) ===

(Rien en annexe.)

=== 8éme semaine: (du 24/03/2014 au 26/03/2014) ===

(Rien en annexe.)

=== 9éme semaine: (du 28/03/2014 au 03/04/2014) ===

[[Fichier:P34_2013_2014_DSC_0061_1_r_2r_semaine_9.jpg|center|thumb|300px|Le réseau R-2R.]]

[[Fichier:P34_2013_2014_DSC_0062_1_4QAM_semaine_9.jpg|center|thumb|300px|4QAM.]]

[[Fichier:P34_2013_2014_DSC_0066_1_16QAM_semaine_9.jpg|center|thumb|300px|16QAM.]]

[[Fichier:P34_2013_2014_DSC_0069_1_64QAM_semaine_9.jpg|center|thumb|300px|64QAM.]]

Pas de photos pour la constellation à 256 points, mais elle a été réalisée.

Pour ce qui est du montage, malgré que la P.L.L., on a un signal d'erreur après filtrage :

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Chaine 1: Vtune (commande du V.C.O.)/Chaine 2: "erreur" de commande]]

Ce qui mets en valeur immédiatement deux problèmes majeurs:

La chaine fonctionne sur le papier, mais lors de sa mise en pratique, il faut penser à mettre une tension d'offset et aussi réaliser une amplification de l'erreur pour avoir des grandeur de commande adapté au Vtune du V.C.O..

On propose l'amélioration suivante (qui sera réalisé à la prochaine séance):

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Proposition de voie d'amélioration.]]

On remarquera que les valeurs des résistances et des capacité on était choisit pour permettre un fonctionnement correct des A.O. (Amplificateur Opérationnel), mais pas pour ce qui de l'asservissement de la boucle par manque de temps.

A la fin de cette, on a eu à démonter le montage à cause de contraintes concernant les mini-circuits (car utilisé en travaux pratiques).

=== 10éme semaine: (rédaction en cours) (du 07/04/2014 au 10/04/2014) ===

Spectres des signaux de la chaine de transmission:

[[Fichier:P34_2013_2014_DSC_0001_allure_spectre_reception_semaine_10.jpg|center|thumb|300px|Spectre en réception.]]

Porteuse utilisé pour la modulation I/Q à environ 60MHz.

P34_2013_2014_DSC_0001_allure_spectre_reception_semaine_10.jpg

Porteuse utilisé pour le transport en fréquence à environ 810MHz:

[[Fichier:P34_2013_2014_DSC_0035_constellation_recupere_PLL_NV_semaine_10.jpg|center|thumb|300px|"Constellation" récupéré avec la PLL défectueuse (on souhaite se verrouillé sur la raie à 868MHz).]]

Question en suspend: faudrai t'il utiliser un filtre passe bande incluant 868Mhz pour pouvoir se verrouillé sur cette fréquence ?

On remarquera sur le fait que l'oscillateur du côté de la chaine d'émission à d'importante non linéarité (on peut observer à l'analyseur de spectre 3 à 4 raies aux fréquences multiples).

Ce qui donne un diagramme de constellation plutot mauvais si l'on fait le montage suivant:

== Annexe B: Digilent Spartan 3 ==

=== Procédure pour faire fonctionner la carte Digilent Spartan 3: ===

Ne connectez pas de connecteur JTAG pendant les installations. Redémarrez après chaque installation.

Tout d'abord, il faut savoir que le l'ISE Webpack 14.6 fonctionne avec la carte (n'utilisez pas la 14.7, elle ne supporte pas la génération spartan 3 !):

Installez donc l'ISE WebPack 14.6 (ou antérieur à condition que celle-ci soit supérieur à la 7.1i (d'aprés leur documentation))

(voir lien utile sur Xilinx)

Une fois l'installation de l'ISE terminé, faites en sorte d'avoir celui que soit opérationnel (la licence est gratuite !).

Installez la "library" ADEPT 2.3 voir le lien utile.

Après vous n'avez plus qu'a utilisez ISE Xilinx normalement et vous serez capable de reconnaitre la carte via la liaison JTAG, et de le programmer.

=== Liens utiles: ===

Lien constructeur/vendeur (avec ressources utiles en bas de la page):

http://www.digilentinc.com/Products/Detail.cfm?Prod=S3BOARD

Lien "Library" pour le câble USB digilent:

http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,66,69&Prod=ADEPT

Lien Xilinx (Pour l'ISE 14.6):

http://www.xilinx.com/products/design-tools/ise-design-suite/index.htm

Lien Xilinx (Pour les versions antérieures veuillez faire attention au système d'exploitation, votre architecture matérielle et le FPGA cible):

(Les informations de compatibilité son sur la page suivante:) (mots clés: xilinx classic(s))

http://www.xilinx.com/tools/classics.htm

=== Procédure pour faire une programmation en volatile: ===

Générer le bitstream, et le charger.

=== Procédure pour faire une programmation en "non"-volatile: ===

Générer le bitstream et l'utiliser pour générer un .mcs qui vous permettra d'inscrire le programme dans la mémoire (E?)PROM.

On remarquera que la programmation en non-volatile est utile pour faire un remise à zéro et recharger le contenu de l'(E?)PROM, mais semble être sensible au débranchement de l'adaptateur d'alimentation de la carte.

=== Exemple de programmation: ===

Voir le lien digilent pour ceci dans cette annexe.

Fichier:P34 2013 2014 DSC 0001 allure spectre reception semaine 10.jpg

2014-04-13T20:09:50Z

Jvaessen :

Fichier:P34 2013 2014 DSC 0035 constellation recupere PLL NV semaine 10.jpg

2014-04-13T20:03:32Z

Jvaessen :

Modem pour le numérique

2014-04-13T19:54:19Z

Jvaessen : /* 9éme semaine: (du 28/03/2014 au 03/04/2014) */

= Modulateur et démodulateur pour communications numériques =

== Cahier des charges ==

=== Présentation générale du projet ===

Dans le cadre des TPs d'électronique et de transmission RF, nous avons découvert qu'il existe plusieurs modes de modulation, pour transmettre un signal modulant.

Celles vues en TP au S7 sont la modulation en amplitude, en fréquence, en phase, en BPSK et en QPSK.

Or les modulations en phase, en fréquence et en amplitude étant celles les plus connues, la modulation en QAM (Modulation d'Amplitude en Quadrature) est quant à elle moins connue, mais tout aussi utilisées:

-pour la TNT en 64 QAM (en France).

[[Fichier:P34_2013_2014_64qam.jpg|300px|thumb|center|Exemple de constellation 64QAM.]]

-pour le WiFi en 64-QAM ou 256-QAM (à vérifier).

Or ces deux dernières étant peu représentées au niveau des travaux pratiques, ce projet permettra de fournir un peu plus de pratique sur les modulations de type QAM (en diagramme I/Q) dans le domaine des radiofréquences (~800MHz).

(Le nombre devant le QAM indique le nombre de points dans le diagramme I/Q qu'on appelle aussi constellation)

On se réserve le droit de faire '''évoluer''' le cahier des charges a posteriori, si certaines contraintes étaient amenées à évoluer ou se préciser.

=== Objectif et intérêt du projet ===

Pour cela, on nous a fourni des modules commerciaux Mini-circuit pouvant travailler dans les radios-fréquences.

Ceux-ci permettront de mettre en place une grande partie de la chaine de transmission (voir schéma de la chaine de transmission).

[[Fichier:P34_2013_2014_Chaine_modulation.PNG|300px|thumb|center|Modulation.]]

[[Fichier:P34_2013_2014_Chaine_demodulation.PNG|300px|thumb|center|Demodulation.]]

On a tout d'abord à mettre en place une carte FPGA et/ou un dispositif permettant d'envoyer un flux de données numériques continuellement pour pouvoir visualiser le diagramme I/Q (mise en valeur du diagramme I/Q et voir même un diagramme un peu plus complexe que le BPSK ou le QPSK).

Le canal de transmission qui sera un simple fil électrique, mais pourra devenir une antenne réceptrice et émettrice si le temps imparti le permet (mise en valeur du et mesure du Bit Error Rate qui sera bien sûr différent suivant le canal de transmission).

Du côté réception ,après démodulation du signal, une remise en forme et une interprétation des données seront réalisées, celle-ci dépendra bien entendu de la provenance du flux de données (constater le succès ou l'échec d'un envoi de données).

Enfin si le temps le permets on pourra mettre en une place un système de codage de l'information avec par exemple un codage redondant permettant de corrigé l'erreur (À définir, on pourra faire constater l'efficacité d'une méthode de codage au choix).

=== Étapes/Déroulement du projet ===

De même que pour le cahier des charges, il se peut que les étapes diffèrent plus ou moins, en fonction des disponibilités, matérielles et contraintes.

==== => Caractérisation des blocs Mini-circuits et épluchage des documentations techniques====
Avant de les utiliser dans la chaine de transmission, nous avons à faire une caractérisation des blocs fournis:

-la caractérisation du VCO.

-l'étude des possibilités offerte par le modulateur (cela déterminera le nombre de points possible dans la constellation, ie savoir si l'on peut aller au-delà de la QPSK).

-la caractérisation des mélangeurs (Mixer), leurs facteurs réels de multiplication.

==== => Utilisation et exploitation des caractérisations ====
On pourra ensuite trouver les paramètres pour régler correctement dans notre chaine de transmission certains de nos sous-systèmes comme la boucle à verrouillage de phase.

==== => Génération d'un flux des données numériques ====
Comme dit précédemment, l'idéal et d'avoir un flux de données numériques transmis en permanence.
Pour cela plusieurs solutions s'offre à nous, on pourra utiliser un montage générateur pseudo aléatoire (un circuit que l'on a fait l'année dernière en Conception de Circuit Électronique).
On pourra "émuler" ce montage avec un Arduino, ou bien même le faire au moyen de la Nanoboard.
On pourra aussi transmettre des chaines de caractère en continu.

==== => Test de la chaine ====
Une fois les étapes précédentes réalisées, on pourra passer au test de la chaine de transmission. Il faudra vérifier le bon fonctionnement en aval, dedans (boucle a verrouillage de phase), et en amont de la chaine de transmission.

==== => Première mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.
Il est possible que la conception d'un dispositif soit nécessaire que ce soit pour les deux mesures du B.E.R..

==== => Antennes ====
Si toutes les étapes précédentes sont satisfaites, on pourra alors faire un canal de transmission plus intéressant, à savoir l'air.
Nous passerons alors à la conception des antennes, émettrice et réceptrice.

==== => Deuxième mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.

==== => Codage de l'information et correction d'erreur ====
En toute fin de ce projet, on pourra même mettre deux dispositifs en aval et en amont de la chaine de transmission.
On réalisera alors un codeur et un décodeur permettant de faire de la détection/correction d'erreur.

==== => Mise en place d'outil de débogage (tout au long)====
La mise en place de simples outils de débogage et primordiale, ceux-ci permettront de vérifier le bon fonctionnement de la chaine.

==== => Proposition d'un sujet de TP (tout au long) ====
Il se trouve que lors du déroulement du projet, on pourra être amené à se poser des questions au niveau des réglages de la chaine de transmission.
Or il est fort probable que les élèves qui travailleront sur ce TP pourront alors se poser les mêmes questions.
C'est pour cela qui sera judicieux de prendre soin de noter les problématiques rencontrées et de donner un certain fil de développement pour venir à bout de la problématique posée.
Ce qui reviendra à proposer des axes/questions sur les manipulations de cette maquette de TP.

== Note valable pour toutes les semaines ==

'''[[Si un point vous semble imprécis, veuillez vous reportez aux détails fournit en annexe.]]'''

== 1éme semaine: (du 27/01/2014 au 01/02/2014) ==

Séance du 05/02/2014 :

Pour bien comprendre les différentes choses à réaliser, on a refait les manipulations vues en TP. On a, pour cela utiliser la maquette didactique TIMS pour générer différent type de modulation:

-la modulation en 4,8,16PSK (on obtient une constellation en forme de cercle).

-La modulation en 4,8,16QAM (on obtient une constellation avec un carré, ou deux: de différentes tailles).

On a très vite dégagé la nécessité de réaliser un montage générateur de tous les mots numériques possibles.
On a donc fait un programme sur arduino qui équivaut au générateur pseudo aléatoire.
Celui-ci est directement inspiré du montage que l'on a réalisé l'année dernière en conception de circuit électronique.

Séance du 06/02/2014 :

Lors de cette séance on a exploré toute les possibilités concernant la communication entre la maquette/carte car cela pour avoir une influecnce non négligeable sur le choix de la carte F.P.G.A. et du design de la maquette.

On a donc aussi fait des recherches concernant les possibilités de communications et les bloc I.P. (Intellectual Properties) permettant de programmer un F.P.G.A.

Et enfin, on a eu une discussion avec un responsable technique pour ce qui de la C.E.M. (Compatibilité Electro-Magnétique)

== 2éme semaine: (du 03/02/2014 au 08/02/2014) ==

Réflexion sur les possibilités possibles et offertes par le sujet pour ce qui est des parties de communications entre la maquette en interne et de son environnement.

[[Fichier:P34_2013_2014_schéma_principe_carte_semaine_2.PNG|300px|thumb|center|Maquette en interne/externe.]]

N'ayant jamais utilisé d'autre carte que la Nanoboard, on s'est attelé à faire des recherches sur la manière de procéder pour programmer une carte F.P.G.A., il se trouve que chaque carte de développement à ses propes manières pour être programmé.

On a pris le soin de notez toutes les questions concernant le F.P.G.A. pour un intervenant industrielle qui assura un cours la semaine prochaine.

== 3éme semaine: (du 10/02/2014 au 15/02/2014) ==

Ayant les oscillateurs commandables en tension, on a pu commencer à faire une manipulation avec les composants Mini Circuit.

Mais après un problème suite à une manipulation l'un des VCOs ne fonctionne plus.

Ce qui nous amène à penser qu'il sera judicieux de prévoir une alimentation au niveau de la carte.

Celle-ci devra être inférieure ou égale à la tension maximale d'alimentation du composant (ceux-ci étant très sensible).

Questions/Réponses:

Comment fait-on pour programmer une carte F.P.G.A. est-ce que la programmation se fait "in situe" ? (in situe : c'est à dire sur la carte elle même)
Oui, c'est ce qui est utilisé, via une câble JTAG.

Est-ce possible faire une interface USB pour permettre à un ordinateur de communiquer avec la maquette/carte via un F.P.G.A. ? Oui.

Est-ce que la gestion de l'interface Ethernet est envisageable ? Oui.

Pour une communication en protocole UDP avec un ordinateur via une liaison Ethernet, est-ce qu'il y a d'autre façon que d'utiliser un Soft Core ?

Oui, il existe aussi bien en Software, qu'en Hardware.

== 4éme semaine: (du 17/02/2014 au 22/02/2014) ==

On a donc repris l'idée de la 2éme semaine.

Après avoir mis en place un cahier des charges au niveau des qualités, bande passante minimale.

Nous avons fait des recherches sur les composants à utiliser (ie CAN, CAN, ...)

Ce qui nous a permis après une édition rapide de schéma électrique (schematic) d'avoir une idée du nombre de pins dont nous aurons besoin sur une carte FPGA afin de réaliser le projet.

Après prospection, il se trouve que nous nous dirigerions vers la carte Digilent Spartan 3, dont l'école était déjà en possession.

Donc nous nous sommes attelés à faire des recherches et des essais sur cette carte et pour notamment trouver un moyen de la faire fonctionner.

== 5éme semaine: (du 03/03/2014 au 08/03/2014) ==

Tout d'abord, après plusieurs heures de recherches et d'essai infructueux, on a fini par trouver les drivers pour le câble USB diligent.

Et donc ainsi avoir un fonctionnement de la communication via le câble JTAG plus propice au fonctionnement de la carte.

On a pu enfin se conforter sur une partie des composants et des dimensionnements pour certains d'entre eux (valeur de résistance,capacité...)

Schématics: Édition de multiple bibliothèque pour Altium, intégrant à la fois schématics et leur empreinte PCB associés.

(On a pu constater qu'un interface 3v3 5v n'est pas forcement nécessaire pour assurer le bon fonctionnement entre deux cartes avec des tensions d'alimentation différentes.)

== 6éme semaine: (du 10/03/2014 au 15/03/2014) ==

On a pu enfin se conforter sur l'ensemble des composants et des choix de régulateur et utilisation d'autre diode Zener.

On trouvera le schéma intégrale avec les bibliothèques nécessaires dans la semaine 5.

Cette semaine à été dédié à l'envoie de la commande des composants au sein du magasin de l'école et du fournisseur.

Après envoi de la commande, il se trouve que le projet a changé d'objectif principal.

Il est maintenant prioritaire de réaliser un code VHDL capable d'évaluer la vitesse de transmission numérique du côté récepteur.

== 7éme semaine: (du 17/03/2014 au 22/03/2014) ==

Pour cette semaine, on s'est concentré sur la réalisation d'un générateur pseudo aléatoire en interne au FPGA.

On réalisera une échelle de résistance afin de réaliser une conversion numérique analogique afin de l'envoyer sur la chaine de transmission.

Ce code de "base" nous permettra de réaliser un flux de données fictif pour obtenir toutes les combinaisons récupérant le résultat du bus.

[[MédiaP34_2013_2014_gene_pseudo_19_03_2014_6_semaine_7.zip|Archive contenant le projet ISE Xilinx.]]

[[Fichier:P34_2013_2014_rtl_semaine_7.PNG|300px|thumb|center|extrait du schéma RTL, on peut y voir clairement les inférences de Xilinx.]]

Ce schéma a deux entrées et une sortie, une entrée d'initialisation, une horloge et une sortie pour la trame en pseudo aléatoire.

On fera l'essaie sur la carte lors de la semaine suivante.

== 8éme semaine: (du 24/03/2014 au 26/03/2014) ==

Aprés le premier test, on pourrait penser que l'on récupère du bruit en sortie de la carte:

[[Fichier:P34_2013_2014_DSC_0024_1_probleme_d_overshoot_semaine_8.jpg|300px|thumb|center|Overshoot.]]

Pour pouvoir remédier à ce problème on a fait une pré-division de l'horloge

[[Fichier:P34_2013_2014_DSC_0037_1_div_freq_semaine_8.jpg|300px|thumb|center|Overshoot après division.]]

[[Fichier:P34_2013_2014_DSC_0039_1_div_freq_zoom_semaine_8.jpg|300px|thumb|center|Overshoot après division (Zoom).]]

Archive contenant toutes les modifications:

[[Média:P34_2013_2014_gene_pseudo_26_03_2014_2_semaine_8.zip|VHDL Semaine 8.]]

On a trouvé un moyen de faire un CNA facilement, via une "échelle dit R-2R". [[http://www.uchobby.com/index.php/2008/01/08/arduino-audio-dac-options/|Pour le réseau R 2R.]]

Il faut encore modifier le VHDL pour pouvoir l'exploiter et ainsi générer une constellation.

== 9éme semaine: (du 28/03/2014 au 03/04/2014) ==

On a pris donc le soin de modifier le VHDL:

[[Média:P34_2013_2014_gene_pseudo_31_03_2014_1_semaine_9.zip|VHDL semaine 9]]

Ce VHDL à été mis à jour, avec deux entrées (initialisation et une horloge) et un bus de sortie (8 bits), avec les trames pseudo-aléatoire.

On envoie ces signaux sur deux C.N.A.s (4 bits chacun) pour générer deux signaux I et Q, on peut voir une constellation se dessiner en mode X-Y.

[[Fichier:P34_2013_2014_DSC_0072_1_Montage_entier_4qam_semaine_9.jpg|300px|thumb|center|Montage avec constellations 4QAM.]]

D'autre constellations réalisées sont disponibles en annexe. On peut monter jusqu'à une constellation de 256 points (2^4*2^4).

On a réalisé le montage complet de toute la chaine de transmission. Il se trouve que la Boucle à Verrouillage de Phase (ou appellée PLL, Phase Loop Locker) ne se verrouille pas sur la porteuse du signal que l'on souhaite récupéré, de ce fait on ne peut pas récupérer les signaux I et Q.

== 10éme semaine: (du 07/04/2014 au 10/04/2014) ==

On a réalisé le montage que l'on évoqué en semaine 9:

P34_2013_2014_DSC_0027_montage_realisee_semaine_10.jpg

[[Fichier:P34_2013_2014_DSC_0027_montage_realisee_semaine_10.jpg|center|thumb|300px|Montage pour amélioré la PLL.]]

Il se trouve qu’après un réglage précis de la tension d'offset permettant d'être un proche de la fréquence à capturé on obtient:

[[Fichier:P34_2013_2014_DSC_0025_PLL_non_verrouillage_semaine_10.jpg|center|thumb|300px|Signaux I/Q après ajout du montage.]]

= Annexes =

== Annexe A: Détails techniques des semaines ==

=== 1éme semaine: (du 27/01/2014 au 01/02/2014) ===

Après on a réfléchi sur la potentielle conception/utilisation d'une carte FPGA.
Il sera judicieux de ne pas se précipiter sur le schéma et la conception/utilisation d'une carte FPGA, sans avoir, au préalable fait le VHDL et le testez avec un banc de test virtuel.
L'intérêt et de mettre en valeur la nécessité ou non de certains signaux pour le schéma de la carte.
On va mettre en oeuvre les connaissances acquises au S7 en VHDL (en TP de Circuit Numérique Programmble).

Pour ce qui est de l'Arduino, on a répondu aux interrogations suivantes (certaines de ces questions paraissent triviales, mais on préfère éviter les surprises):

Quelle est la vitesse maximale de la communication série de l'Arduino ?
-115200bauds

Est-ce que, un programme de type "Analog Write" est-il une vraie sortie analogique ?

-Non, c'est juste une PWM. Elle sera exploitable pour faire les signales I/Q mais très contraignantes, car il faudra filtré le signal, et ce sera beaucoup trop lent (du au fait que la modulation est faite au alentour de 850Mhz), le FPGA sera un passage obligé cela ouvrira les portes d'un plus grand débit.

==== Manipulation réalisée sur la maquette TIMS : ====

On a fait un des montages présenté dans l'ouvrage "Volume D1 Fundamental Digital Experiments" dans le but de visualiser l’objectif à atteindre.

On obtient la constellation suivante (16QAM):

[[Fichier:P34_2013_2014_constelation_tims_semaine_1.PNG|300px|thumb|center|Constellation visualisé en mode X-Y.]]

Ce qui correspond à deux signaux en visualisation temporelle de cette forme :

[[Fichier:P34_2013_2014_constelation_temporelle_tims_semaine_1.PNG|300px|thumb|center|Signaux I et Q. (Image très flouté, à remplacer)]]

On pourra facilement obtenir le même résultat en générant un bus de trame pseudo aléatoire et en l'injectant dans un C.N.A. (Conversion Numérique Analogique)

==== Code Arduino réalisé: ====

[[Fichier:P34_2013_2014_schema_electronique_generateur_pseudo_aleatoire.png|300px|thumb|center|Schéma électronique du générateur pseudo aléatoire.]]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_chrono_simule.PNG|300px|thumb|center|Résultat de la simulation du générateur pseudo aléatoire (on a eu la même chose en pratique).]]

[code]
/*A peut être supprimer*/
#include <avr/io.h>
#include <util/delay.h>

void output_init(void){
DDRB |= 0x02; // PIN 8,9 sont les deux sorties.
}

int main(void){
int r1=1,r2=0,r3=0,r4=0,r5=0,retard=0;
PORTB=0x00;
while(1)
{
r5=r4;//chaque affectation représente une recopie de la bascule sur le "front montant", ici c'est simplement l’exécution du code.
r4=r3;
r3=r2;
r2=r1;
r1=r4^r5;
PORTB=0x01*r1+0x02*retard;//écriture des signaux
_delay_ms(10);//le "front montant", ce qui permet de faire un genre d'horloge.
retard=r5;//déphasage du signal
}
return 0;
}
[/code]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_arduino.jpg|300px|thumb|center|Resultat avec le generateur pseudo aléatoire "émuler" avec l'Arduino.]]

Comparaison carte réelle/résultat Arduino:

C'était exactement les signaux attendus (même s'il y un décalage a par rapport à l'original).

On aura bien pour une QPSK (4PSK) tous les couples (ie 00,01,11 et 10).

À propos de l'arduino, on pourra envisager une amélioration pour générer une séquence plus longue:

-il faudra simplement utiliser un tableau d'entier.

-paramétrer sa taille avec un N par exemple.

-N correspondra à la taille de séquence de longueur 2^N.

Voir la section "Code Arduino réalisé" en annexe B dans la semaine correspondante.

==== Possibilités de communications: ====

Exploration des possibilités de communication entre le PC et la carte en amont:

=====-> Ethernet: =====

*+ Vitesse de transmission (~10M-100M-G)bauds

*- La gestion du flux de données doit être faite par un microcontrôleur (celui-ci pourra être implémenté un bloc I.P. à l'intérieur du FPGA)

-> - Haute consommation de CLB du FPGA.

=====-> SPI (communication série): =====

*- Vitesse de transmission

-> Arduino capable de communiquer jusqu'a 115200 bauds

-> D'après certaines discussions on pourrait « pousser » au-delà : voir le lien des sujets Raspberry Pi.

=====-> I2C : =====

Communication abandonné, ce n'est pas une priorité.

==== À propos des blocs I.P.: ====

En consultant les ordinateurs et en s'appuyant des TPs de CNP, on constate que les blocs suivants existent:

- Xilinx Microblaze/Xilinx Power PC ("µP FPGA")

-> Est-ce possible d'utiliser ces blocs I.P. pour programmer un FPGA sur une carte autre que la Nanoboard ? Comment ?

- EMACx (Ethernet Media Acess Control)(:lien physique entre processeurs et "standart Physical Layer device IEEE802.3")

===== Conception de la carte: =====

L'idéal est de se documenter sur la Compatibilité électromagnétique.

=== 2éme semaine: (du 03/02/2014 au 08/02/2014) ===

(Rien en annexe.)

=== 3éme semaine: (du 10/02/2014 au 15/02/2014) ===

Lors de cette semaine, après avoir eu le problème de manipulation, nous avons pus prendre connaissance d'un certain montage qui s’avéra utile pour la conception de la carte/maquette.

[[Fichier:P34_2013_2014_schéma_limiteur_de_courant_semaine_3.PNG|300px|thumb|center|Schéma limiteur de courant.]]

On remarquera que ce montage se retrouve dans la partie "typical application" de la documentation technique du 7805.

=== 4éme semaine: (du 17/02/2014 au 22/02/2014) ===

On souhaite pouvoir réaliser une communication unidirectionnel ou même transmettre un signal audio ce qui nous contraint à une bande passante minimal de 48kHz, on prendra 200kHz (Pour être bien au delà de la conditions du théorème de Shannon): le but serait donc de branchez par exemple une source audio quelconque puis de la transmettre à travers la maquette et de la recomposer en fin de chaine.

Après édition rapide du schématique on en dégage qu'il nous faudra un minimum d'environ 50 entrées/sorties. Mais ceci ce nombre sera très probablement revue à la hausse lors de prochaine séance.

Voici la carte que l'on utilisera dans la suite du projet:

[[Fichier:P34_2013_2014_S3BOARD-top-400_semaine_4.gif|300px|thumb|center|Digilent Spartan 3.]]

=== 5éme semaine: (du 03/03/2014 au 08/03/2014) ===

Lien vers le Design complet avec les librairies incluses (on remarquera qu'il serait judicieux d’installer toutes les librairies avant d’essayer d'ouvrir le schéma)

A notez aussi que l'on trouvera des reliques de feuilles Excel permettant de trouver rapidement des ratios dans la série E12.

[[Média:P34_2013_2014_Design_pcb_plus_librairies_semaine_5_6.zip|Schéma + Bibliothèques.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.pdf|Schéma en PDF.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.png|Schéma au format A2.]]

=== 6éme semaine: (du 10/03/2014 au 15/03/2014) ===

(Rien en annexe.)

=== 7éme semaine: (du 17/03/2014 au 22/03/2014) ===

(Rien en annexe.)

=== 8éme semaine: (du 24/03/2014 au 26/03/2014) ===

(Rien en annexe.)

=== 9éme semaine: (du 28/03/2014 au 03/04/2014) ===

[[Fichier:P34_2013_2014_DSC_0061_1_r_2r_semaine_9.jpg|center|thumb|300px|Le réseau R-2R.]]

[[Fichier:P34_2013_2014_DSC_0062_1_4QAM_semaine_9.jpg|center|thumb|300px|4QAM.]]

[[Fichier:P34_2013_2014_DSC_0066_1_16QAM_semaine_9.jpg|center|thumb|300px|16QAM.]]

[[Fichier:P34_2013_2014_DSC_0069_1_64QAM_semaine_9.jpg|center|thumb|300px|64QAM.]]

Pas de photos pour la constellation à 256 points, mais elle a été réalisée.

Pour ce qui est du montage, malgré que la P.L.L., on a un signal d'erreur après filtrage :

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Chaine 1: Vtune (commande du V.C.O.)/Chaine 2: "erreur" de commande]]

Ce qui mets en valeur immédiatement deux problèmes majeurs:

La chaine fonctionne sur le papier, mais lors de sa mise en pratique, il faut penser à mettre une tension d'offset et aussi réaliser une amplification de l'erreur pour avoir des grandeur de commande adapté au Vtune du V.C.O..

On propose l'amélioration suivante (qui sera réalisé à la prochaine séance):

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Proposition de voie d'amélioration.]]

On remarquera que les valeurs des résistances et des capacité on était choisit pour permettre un fonctionnement correct des A.O. (Amplificateur Opérationnel), mais pas pour ce qui de l'asservissement de la boucle par manque de temps.

A la fin de cette, on a eu à démonter le montage à cause de contraintes concernant les mini-circuits (car utilisé en travaux pratiques).

=== 10éme semaine: (rédaction en cours) (du 07/04/2014 au 10/04/2014) ===

== Annexe B: Digilent Spartan 3 ==

=== Procédure pour faire fonctionner la carte Digilent Spartan 3: ===

Ne connectez pas de connecteur JTAG pendant les installations. Redémarrez après chaque installation.

Tout d'abord, il faut savoir que le l'ISE Webpack 14.6 fonctionne avec la carte (n'utilisez pas la 14.7, elle ne supporte pas la génération spartan 3 !):

Installez donc l'ISE WebPack 14.6 (ou antérieur à condition que celle-ci soit supérieur à la 7.1i (d'aprés leur documentation))

(voir lien utile sur Xilinx)

Une fois l'installation de l'ISE terminé, faites en sorte d'avoir celui que soit opérationnel (la licence est gratuite !).

Installez la "library" ADEPT 2.3 voir le lien utile.

Après vous n'avez plus qu'a utilisez ISE Xilinx normalement et vous serez capable de reconnaitre la carte via la liaison JTAG, et de le programmer.

=== Liens utiles: ===

Lien constructeur/vendeur (avec ressources utiles en bas de la page):

http://www.digilentinc.com/Products/Detail.cfm?Prod=S3BOARD

Lien "Library" pour le câble USB digilent:

http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,66,69&Prod=ADEPT

Lien Xilinx (Pour l'ISE 14.6):

http://www.xilinx.com/products/design-tools/ise-design-suite/index.htm

Lien Xilinx (Pour les versions antérieures veuillez faire attention au système d'exploitation, votre architecture matérielle et le FPGA cible):

(Les informations de compatibilité son sur la page suivante:) (mots clés: xilinx classic(s))

http://www.xilinx.com/tools/classics.htm

=== Procédure pour faire une programmation en volatile: ===

Générer le bitstream, et le charger.

=== Procédure pour faire une programmation en "non"-volatile: ===

Générer le bitstream et l'utiliser pour générer un .mcs qui vous permettra d'inscrire le programme dans la mémoire (E?)PROM.

On remarquera que la programmation en non-volatile est utile pour faire un remise à zéro et recharger le contenu de l'(E?)PROM, mais semble être sensible au débranchement de l'adaptateur d'alimentation de la carte.

=== Exemple de programmation: ===

Voir le lien digilent pour ceci dans cette annexe.

Modem pour le numérique

2014-04-13T19:53:41Z

Jvaessen : /* 10éme semaine: (rédaction en cours) (du 07/04/2014 au 10/04/2014) */

= Modulateur et démodulateur pour communications numériques =

== Cahier des charges ==

=== Présentation générale du projet ===

Dans le cadre des TPs d'électronique et de transmission RF, nous avons découvert qu'il existe plusieurs modes de modulation, pour transmettre un signal modulant.

Celles vues en TP au S7 sont la modulation en amplitude, en fréquence, en phase, en BPSK et en QPSK.

Or les modulations en phase, en fréquence et en amplitude étant celles les plus connues, la modulation en QAM (Modulation d'Amplitude en Quadrature) est quant à elle moins connue, mais tout aussi utilisées:

-pour la TNT en 64 QAM (en France).

[[Fichier:P34_2013_2014_64qam.jpg|300px|thumb|center|Exemple de constellation 64QAM.]]

-pour le WiFi en 64-QAM ou 256-QAM (à vérifier).

Or ces deux dernières étant peu représentées au niveau des travaux pratiques, ce projet permettra de fournir un peu plus de pratique sur les modulations de type QAM (en diagramme I/Q) dans le domaine des radiofréquences (~800MHz).

(Le nombre devant le QAM indique le nombre de points dans le diagramme I/Q qu'on appelle aussi constellation)

On se réserve le droit de faire '''évoluer''' le cahier des charges a posteriori, si certaines contraintes étaient amenées à évoluer ou se préciser.

=== Objectif et intérêt du projet ===

Pour cela, on nous a fourni des modules commerciaux Mini-circuit pouvant travailler dans les radios-fréquences.

Ceux-ci permettront de mettre en place une grande partie de la chaine de transmission (voir schéma de la chaine de transmission).

[[Fichier:P34_2013_2014_Chaine_modulation.PNG|300px|thumb|center|Modulation.]]

[[Fichier:P34_2013_2014_Chaine_demodulation.PNG|300px|thumb|center|Demodulation.]]

On a tout d'abord à mettre en place une carte FPGA et/ou un dispositif permettant d'envoyer un flux de données numériques continuellement pour pouvoir visualiser le diagramme I/Q (mise en valeur du diagramme I/Q et voir même un diagramme un peu plus complexe que le BPSK ou le QPSK).

Le canal de transmission qui sera un simple fil électrique, mais pourra devenir une antenne réceptrice et émettrice si le temps imparti le permet (mise en valeur du et mesure du Bit Error Rate qui sera bien sûr différent suivant le canal de transmission).

Du côté réception ,après démodulation du signal, une remise en forme et une interprétation des données seront réalisées, celle-ci dépendra bien entendu de la provenance du flux de données (constater le succès ou l'échec d'un envoi de données).

Enfin si le temps le permets on pourra mettre en une place un système de codage de l'information avec par exemple un codage redondant permettant de corrigé l'erreur (À définir, on pourra faire constater l'efficacité d'une méthode de codage au choix).

=== Étapes/Déroulement du projet ===

De même que pour le cahier des charges, il se peut que les étapes diffèrent plus ou moins, en fonction des disponibilités, matérielles et contraintes.

==== => Caractérisation des blocs Mini-circuits et épluchage des documentations techniques====
Avant de les utiliser dans la chaine de transmission, nous avons à faire une caractérisation des blocs fournis:

-la caractérisation du VCO.

-l'étude des possibilités offerte par le modulateur (cela déterminera le nombre de points possible dans la constellation, ie savoir si l'on peut aller au-delà de la QPSK).

-la caractérisation des mélangeurs (Mixer), leurs facteurs réels de multiplication.

==== => Utilisation et exploitation des caractérisations ====
On pourra ensuite trouver les paramètres pour régler correctement dans notre chaine de transmission certains de nos sous-systèmes comme la boucle à verrouillage de phase.

==== => Génération d'un flux des données numériques ====
Comme dit précédemment, l'idéal et d'avoir un flux de données numériques transmis en permanence.
Pour cela plusieurs solutions s'offre à nous, on pourra utiliser un montage générateur pseudo aléatoire (un circuit que l'on a fait l'année dernière en Conception de Circuit Électronique).
On pourra "émuler" ce montage avec un Arduino, ou bien même le faire au moyen de la Nanoboard.
On pourra aussi transmettre des chaines de caractère en continu.

==== => Test de la chaine ====
Une fois les étapes précédentes réalisées, on pourra passer au test de la chaine de transmission. Il faudra vérifier le bon fonctionnement en aval, dedans (boucle a verrouillage de phase), et en amont de la chaine de transmission.

==== => Première mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.
Il est possible que la conception d'un dispositif soit nécessaire que ce soit pour les deux mesures du B.E.R..

==== => Antennes ====
Si toutes les étapes précédentes sont satisfaites, on pourra alors faire un canal de transmission plus intéressant, à savoir l'air.
Nous passerons alors à la conception des antennes, émettrice et réceptrice.

==== => Deuxième mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.

==== => Codage de l'information et correction d'erreur ====
En toute fin de ce projet, on pourra même mettre deux dispositifs en aval et en amont de la chaine de transmission.
On réalisera alors un codeur et un décodeur permettant de faire de la détection/correction d'erreur.

==== => Mise en place d'outil de débogage (tout au long)====
La mise en place de simples outils de débogage et primordiale, ceux-ci permettront de vérifier le bon fonctionnement de la chaine.

==== => Proposition d'un sujet de TP (tout au long) ====
Il se trouve que lors du déroulement du projet, on pourra être amené à se poser des questions au niveau des réglages de la chaine de transmission.
Or il est fort probable que les élèves qui travailleront sur ce TP pourront alors se poser les mêmes questions.
C'est pour cela qui sera judicieux de prendre soin de noter les problématiques rencontrées et de donner un certain fil de développement pour venir à bout de la problématique posée.
Ce qui reviendra à proposer des axes/questions sur les manipulations de cette maquette de TP.

== Note valable pour toutes les semaines ==

'''[[Si un point vous semble imprécis, veuillez vous reportez aux détails fournit en annexe.]]'''

== 1éme semaine: (du 27/01/2014 au 01/02/2014) ==

Séance du 05/02/2014 :

Pour bien comprendre les différentes choses à réaliser, on a refait les manipulations vues en TP. On a, pour cela utiliser la maquette didactique TIMS pour générer différent type de modulation:

-la modulation en 4,8,16PSK (on obtient une constellation en forme de cercle).

-La modulation en 4,8,16QAM (on obtient une constellation avec un carré, ou deux: de différentes tailles).

On a très vite dégagé la nécessité de réaliser un montage générateur de tous les mots numériques possibles.
On a donc fait un programme sur arduino qui équivaut au générateur pseudo aléatoire.
Celui-ci est directement inspiré du montage que l'on a réalisé l'année dernière en conception de circuit électronique.

Séance du 06/02/2014 :

Lors de cette séance on a exploré toute les possibilités concernant la communication entre la maquette/carte car cela pour avoir une influecnce non négligeable sur le choix de la carte F.P.G.A. et du design de la maquette.

On a donc aussi fait des recherches concernant les possibilités de communications et les bloc I.P. (Intellectual Properties) permettant de programmer un F.P.G.A.

Et enfin, on a eu une discussion avec un responsable technique pour ce qui de la C.E.M. (Compatibilité Electro-Magnétique)

== 2éme semaine: (du 03/02/2014 au 08/02/2014) ==

Réflexion sur les possibilités possibles et offertes par le sujet pour ce qui est des parties de communications entre la maquette en interne et de son environnement.

[[Fichier:P34_2013_2014_schéma_principe_carte_semaine_2.PNG|300px|thumb|center|Maquette en interne/externe.]]

N'ayant jamais utilisé d'autre carte que la Nanoboard, on s'est attelé à faire des recherches sur la manière de procéder pour programmer une carte F.P.G.A., il se trouve que chaque carte de développement à ses propes manières pour être programmé.

On a pris le soin de notez toutes les questions concernant le F.P.G.A. pour un intervenant industrielle qui assura un cours la semaine prochaine.

== 3éme semaine: (du 10/02/2014 au 15/02/2014) ==

Ayant les oscillateurs commandables en tension, on a pu commencer à faire une manipulation avec les composants Mini Circuit.

Mais après un problème suite à une manipulation l'un des VCOs ne fonctionne plus.

Ce qui nous amène à penser qu'il sera judicieux de prévoir une alimentation au niveau de la carte.

Celle-ci devra être inférieure ou égale à la tension maximale d'alimentation du composant (ceux-ci étant très sensible).

Questions/Réponses:

Comment fait-on pour programmer une carte F.P.G.A. est-ce que la programmation se fait "in situe" ? (in situe : c'est à dire sur la carte elle même)
Oui, c'est ce qui est utilisé, via une câble JTAG.

Est-ce possible faire une interface USB pour permettre à un ordinateur de communiquer avec la maquette/carte via un F.P.G.A. ? Oui.

Est-ce que la gestion de l'interface Ethernet est envisageable ? Oui.

Pour une communication en protocole UDP avec un ordinateur via une liaison Ethernet, est-ce qu'il y a d'autre façon que d'utiliser un Soft Core ?

Oui, il existe aussi bien en Software, qu'en Hardware.

== 4éme semaine: (du 17/02/2014 au 22/02/2014) ==

On a donc repris l'idée de la 2éme semaine.

Après avoir mis en place un cahier des charges au niveau des qualités, bande passante minimale.

Nous avons fait des recherches sur les composants à utiliser (ie CAN, CAN, ...)

Ce qui nous a permis après une édition rapide de schéma électrique (schematic) d'avoir une idée du nombre de pins dont nous aurons besoin sur une carte FPGA afin de réaliser le projet.

Après prospection, il se trouve que nous nous dirigerions vers la carte Digilent Spartan 3, dont l'école était déjà en possession.

Donc nous nous sommes attelés à faire des recherches et des essais sur cette carte et pour notamment trouver un moyen de la faire fonctionner.

== 5éme semaine: (du 03/03/2014 au 08/03/2014) ==

Tout d'abord, après plusieurs heures de recherches et d'essai infructueux, on a fini par trouver les drivers pour le câble USB diligent.

Et donc ainsi avoir un fonctionnement de la communication via le câble JTAG plus propice au fonctionnement de la carte.

On a pu enfin se conforter sur une partie des composants et des dimensionnements pour certains d'entre eux (valeur de résistance,capacité...)

Schématics: Édition de multiple bibliothèque pour Altium, intégrant à la fois schématics et leur empreinte PCB associés.

(On a pu constater qu'un interface 3v3 5v n'est pas forcement nécessaire pour assurer le bon fonctionnement entre deux cartes avec des tensions d'alimentation différentes.)

== 6éme semaine: (du 10/03/2014 au 15/03/2014) ==

On a pu enfin se conforter sur l'ensemble des composants et des choix de régulateur et utilisation d'autre diode Zener.

On trouvera le schéma intégrale avec les bibliothèques nécessaires dans la semaine 5.

Cette semaine à été dédié à l'envoie de la commande des composants au sein du magasin de l'école et du fournisseur.

Après envoi de la commande, il se trouve que le projet a changé d'objectif principal.

Il est maintenant prioritaire de réaliser un code VHDL capable d'évaluer la vitesse de transmission numérique du côté récepteur.

== 7éme semaine: (du 17/03/2014 au 22/03/2014) ==

Pour cette semaine, on s'est concentré sur la réalisation d'un générateur pseudo aléatoire en interne au FPGA.

On réalisera une échelle de résistance afin de réaliser une conversion numérique analogique afin de l'envoyer sur la chaine de transmission.

Ce code de "base" nous permettra de réaliser un flux de données fictif pour obtenir toutes les combinaisons récupérant le résultat du bus.

[[MédiaP34_2013_2014_gene_pseudo_19_03_2014_6_semaine_7.zip|Archive contenant le projet ISE Xilinx.]]

[[Fichier:P34_2013_2014_rtl_semaine_7.PNG|300px|thumb|center|extrait du schéma RTL, on peut y voir clairement les inférences de Xilinx.]]

Ce schéma a deux entrées et une sortie, une entrée d'initialisation, une horloge et une sortie pour la trame en pseudo aléatoire.

On fera l'essaie sur la carte lors de la semaine suivante.

== 8éme semaine: (du 24/03/2014 au 26/03/2014) ==

Aprés le premier test, on pourrait penser que l'on récupère du bruit en sortie de la carte:

[[Fichier:P34_2013_2014_DSC_0024_1_probleme_d_overshoot_semaine_8.jpg|300px|thumb|center|Overshoot.]]

Pour pouvoir remédier à ce problème on a fait une pré-division de l'horloge

[[Fichier:P34_2013_2014_DSC_0037_1_div_freq_semaine_8.jpg|300px|thumb|center|Overshoot après division.]]

[[Fichier:P34_2013_2014_DSC_0039_1_div_freq_zoom_semaine_8.jpg|300px|thumb|center|Overshoot après division (Zoom).]]

Archive contenant toutes les modifications:

[[Média:P34_2013_2014_gene_pseudo_26_03_2014_2_semaine_8.zip|VHDL Semaine 8.]]

On a trouvé un moyen de faire un CNA facilement, via une "échelle dit R-2R". [[http://www.uchobby.com/index.php/2008/01/08/arduino-audio-dac-options/|Pour le réseau R 2R.]]

Il faut encore modifier le VHDL pour pouvoir l'exploiter et ainsi générer une constellation.

== 9éme semaine: (du 28/03/2014 au 03/04/2014) ==

On a pris donc le soin de modifier le VHDL:

[[Média:P34_2013_2014_gene_pseudo_31_03_2014_1_semaine_9.zip|VHDL semaine 9]]

Ce VHDL à été mis à jour, avec deux entrées (initialisation et une horloge) et un bus de sortie, avec les trames pseudo-aléatoire.

On envoie ces signaux sur deux C.N.A.s (4 bits chacun) pour générer deux signaux I et Q, on peut voir une constellation se dessiner en mode X-Y.

[[Fichier:P34_2013_2014_DSC_0072_1_Montage_entier_4qam_semaine_9.jpg|300px|thumb|center|Montage avec constellations 4QAM.]]

D'autre constellations réalisées sont disponibles en annexe. On peut monter jusqu'à une constellation de 256 points (2^4*2^4).

On a réalisé le montage complet de toute la chaine de transmission. Il se trouve que la Boucle à Verrouillage de Phase (ou appellée PLL, Phase Loop Locker) ne se verrouille pas sur la porteuse du signal que l'on souhaite récupéré, de ce fait on ne peut pas récupérer les signaux I et Q.

== 10éme semaine: (du 07/04/2014 au 10/04/2014) ==

On a réalisé le montage que l'on évoqué en semaine 9:

P34_2013_2014_DSC_0027_montage_realisee_semaine_10.jpg

[[Fichier:P34_2013_2014_DSC_0027_montage_realisee_semaine_10.jpg|center|thumb|300px|Montage pour amélioré la PLL.]]

Il se trouve qu’après un réglage précis de la tension d'offset permettant d'être un proche de la fréquence à capturé on obtient:

[[Fichier:P34_2013_2014_DSC_0025_PLL_non_verrouillage_semaine_10.jpg|center|thumb|300px|Signaux I/Q après ajout du montage.]]

= Annexes =

== Annexe A: Détails techniques des semaines ==

=== 1éme semaine: (du 27/01/2014 au 01/02/2014) ===

Après on a réfléchi sur la potentielle conception/utilisation d'une carte FPGA.
Il sera judicieux de ne pas se précipiter sur le schéma et la conception/utilisation d'une carte FPGA, sans avoir, au préalable fait le VHDL et le testez avec un banc de test virtuel.
L'intérêt et de mettre en valeur la nécessité ou non de certains signaux pour le schéma de la carte.
On va mettre en oeuvre les connaissances acquises au S7 en VHDL (en TP de Circuit Numérique Programmble).

Pour ce qui est de l'Arduino, on a répondu aux interrogations suivantes (certaines de ces questions paraissent triviales, mais on préfère éviter les surprises):

Quelle est la vitesse maximale de la communication série de l'Arduino ?
-115200bauds

Est-ce que, un programme de type "Analog Write" est-il une vraie sortie analogique ?

-Non, c'est juste une PWM. Elle sera exploitable pour faire les signales I/Q mais très contraignantes, car il faudra filtré le signal, et ce sera beaucoup trop lent (du au fait que la modulation est faite au alentour de 850Mhz), le FPGA sera un passage obligé cela ouvrira les portes d'un plus grand débit.

==== Manipulation réalisée sur la maquette TIMS : ====

On a fait un des montages présenté dans l'ouvrage "Volume D1 Fundamental Digital Experiments" dans le but de visualiser l’objectif à atteindre.

On obtient la constellation suivante (16QAM):

[[Fichier:P34_2013_2014_constelation_tims_semaine_1.PNG|300px|thumb|center|Constellation visualisé en mode X-Y.]]

Ce qui correspond à deux signaux en visualisation temporelle de cette forme :

[[Fichier:P34_2013_2014_constelation_temporelle_tims_semaine_1.PNG|300px|thumb|center|Signaux I et Q. (Image très flouté, à remplacer)]]

On pourra facilement obtenir le même résultat en générant un bus de trame pseudo aléatoire et en l'injectant dans un C.N.A. (Conversion Numérique Analogique)

==== Code Arduino réalisé: ====

[[Fichier:P34_2013_2014_schema_electronique_generateur_pseudo_aleatoire.png|300px|thumb|center|Schéma électronique du générateur pseudo aléatoire.]]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_chrono_simule.PNG|300px|thumb|center|Résultat de la simulation du générateur pseudo aléatoire (on a eu la même chose en pratique).]]

[code]
/*A peut être supprimer*/
#include <avr/io.h>
#include <util/delay.h>

void output_init(void){
DDRB |= 0x02; // PIN 8,9 sont les deux sorties.
}

int main(void){
int r1=1,r2=0,r3=0,r4=0,r5=0,retard=0;
PORTB=0x00;
while(1)
{
r5=r4;//chaque affectation représente une recopie de la bascule sur le "front montant", ici c'est simplement l’exécution du code.
r4=r3;
r3=r2;
r2=r1;
r1=r4^r5;
PORTB=0x01*r1+0x02*retard;//écriture des signaux
_delay_ms(10);//le "front montant", ce qui permet de faire un genre d'horloge.
retard=r5;//déphasage du signal
}
return 0;
}
[/code]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_arduino.jpg|300px|thumb|center|Resultat avec le generateur pseudo aléatoire "émuler" avec l'Arduino.]]

Comparaison carte réelle/résultat Arduino:

C'était exactement les signaux attendus (même s'il y un décalage a par rapport à l'original).

On aura bien pour une QPSK (4PSK) tous les couples (ie 00,01,11 et 10).

À propos de l'arduino, on pourra envisager une amélioration pour générer une séquence plus longue:

-il faudra simplement utiliser un tableau d'entier.

-paramétrer sa taille avec un N par exemple.

-N correspondra à la taille de séquence de longueur 2^N.

Voir la section "Code Arduino réalisé" en annexe B dans la semaine correspondante.

==== Possibilités de communications: ====

Exploration des possibilités de communication entre le PC et la carte en amont:

=====-> Ethernet: =====

*+ Vitesse de transmission (~10M-100M-G)bauds

*- La gestion du flux de données doit être faite par un microcontrôleur (celui-ci pourra être implémenté un bloc I.P. à l'intérieur du FPGA)

-> - Haute consommation de CLB du FPGA.

=====-> SPI (communication série): =====

*- Vitesse de transmission

-> Arduino capable de communiquer jusqu'a 115200 bauds

-> D'après certaines discussions on pourrait « pousser » au-delà : voir le lien des sujets Raspberry Pi.

=====-> I2C : =====

Communication abandonné, ce n'est pas une priorité.

==== À propos des blocs I.P.: ====

En consultant les ordinateurs et en s'appuyant des TPs de CNP, on constate que les blocs suivants existent:

- Xilinx Microblaze/Xilinx Power PC ("µP FPGA")

-> Est-ce possible d'utiliser ces blocs I.P. pour programmer un FPGA sur une carte autre que la Nanoboard ? Comment ?

- EMACx (Ethernet Media Acess Control)(:lien physique entre processeurs et "standart Physical Layer device IEEE802.3")

===== Conception de la carte: =====

L'idéal est de se documenter sur la Compatibilité électromagnétique.

=== 2éme semaine: (du 03/02/2014 au 08/02/2014) ===

(Rien en annexe.)

=== 3éme semaine: (du 10/02/2014 au 15/02/2014) ===

Lors de cette semaine, après avoir eu le problème de manipulation, nous avons pus prendre connaissance d'un certain montage qui s’avéra utile pour la conception de la carte/maquette.

[[Fichier:P34_2013_2014_schéma_limiteur_de_courant_semaine_3.PNG|300px|thumb|center|Schéma limiteur de courant.]]

On remarquera que ce montage se retrouve dans la partie "typical application" de la documentation technique du 7805.

=== 4éme semaine: (du 17/02/2014 au 22/02/2014) ===

On souhaite pouvoir réaliser une communication unidirectionnel ou même transmettre un signal audio ce qui nous contraint à une bande passante minimal de 48kHz, on prendra 200kHz (Pour être bien au delà de la conditions du théorème de Shannon): le but serait donc de branchez par exemple une source audio quelconque puis de la transmettre à travers la maquette et de la recomposer en fin de chaine.

Après édition rapide du schématique on en dégage qu'il nous faudra un minimum d'environ 50 entrées/sorties. Mais ceci ce nombre sera très probablement revue à la hausse lors de prochaine séance.

Voici la carte que l'on utilisera dans la suite du projet:

[[Fichier:P34_2013_2014_S3BOARD-top-400_semaine_4.gif|300px|thumb|center|Digilent Spartan 3.]]

=== 5éme semaine: (du 03/03/2014 au 08/03/2014) ===

Lien vers le Design complet avec les librairies incluses (on remarquera qu'il serait judicieux d’installer toutes les librairies avant d’essayer d'ouvrir le schéma)

A notez aussi que l'on trouvera des reliques de feuilles Excel permettant de trouver rapidement des ratios dans la série E12.

[[Média:P34_2013_2014_Design_pcb_plus_librairies_semaine_5_6.zip|Schéma + Bibliothèques.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.pdf|Schéma en PDF.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.png|Schéma au format A2.]]

=== 6éme semaine: (du 10/03/2014 au 15/03/2014) ===

(Rien en annexe.)

=== 7éme semaine: (du 17/03/2014 au 22/03/2014) ===

(Rien en annexe.)

=== 8éme semaine: (du 24/03/2014 au 26/03/2014) ===

(Rien en annexe.)

=== 9éme semaine: (du 28/03/2014 au 03/04/2014) ===

[[Fichier:P34_2013_2014_DSC_0061_1_r_2r_semaine_9.jpg|center|thumb|300px|Le réseau R-2R.]]

[[Fichier:P34_2013_2014_DSC_0062_1_4QAM_semaine_9.jpg|center|thumb|300px|4QAM.]]

[[Fichier:P34_2013_2014_DSC_0066_1_16QAM_semaine_9.jpg|center|thumb|300px|16QAM.]]

[[Fichier:P34_2013_2014_DSC_0069_1_64QAM_semaine_9.jpg|center|thumb|300px|64QAM.]]

Pas de photos pour la constellation à 256 points, mais elle a été réalisée.

Pour ce qui est du montage, malgré que la P.L.L., on a un signal d'erreur après filtrage :

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Chaine 1: Vtune (commande du V.C.O.)/Chaine 2: "erreur" de commande]]

Ce qui mets en valeur immédiatement deux problèmes majeurs:

La chaine fonctionne sur le papier, mais lors de sa mise en pratique, il faut penser à mettre une tension d'offset et aussi réaliser une amplification de l'erreur pour avoir des grandeur de commande adapté au Vtune du V.C.O..

On propose l'amélioration suivante (qui sera réalisé à la prochaine séance):

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Proposition de voie d'amélioration.]]

On remarquera que les valeurs des résistances et des capacité on était choisit pour permettre un fonctionnement correct des A.O. (Amplificateur Opérationnel), mais pas pour ce qui de l'asservissement de la boucle par manque de temps.

A la fin de cette, on a eu à démonter le montage à cause de contraintes concernant les mini-circuits (car utilisé en travaux pratiques).

=== 10éme semaine: (rédaction en cours) (du 07/04/2014 au 10/04/2014) ===

== Annexe B: Digilent Spartan 3 ==

=== Procédure pour faire fonctionner la carte Digilent Spartan 3: ===

Ne connectez pas de connecteur JTAG pendant les installations. Redémarrez après chaque installation.

Tout d'abord, il faut savoir que le l'ISE Webpack 14.6 fonctionne avec la carte (n'utilisez pas la 14.7, elle ne supporte pas la génération spartan 3 !):

Installez donc l'ISE WebPack 14.6 (ou antérieur à condition que celle-ci soit supérieur à la 7.1i (d'aprés leur documentation))

(voir lien utile sur Xilinx)

Une fois l'installation de l'ISE terminé, faites en sorte d'avoir celui que soit opérationnel (la licence est gratuite !).

Installez la "library" ADEPT 2.3 voir le lien utile.

Après vous n'avez plus qu'a utilisez ISE Xilinx normalement et vous serez capable de reconnaitre la carte via la liaison JTAG, et de le programmer.

=== Liens utiles: ===

Lien constructeur/vendeur (avec ressources utiles en bas de la page):

http://www.digilentinc.com/Products/Detail.cfm?Prod=S3BOARD

Lien "Library" pour le câble USB digilent:

http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,66,69&Prod=ADEPT

Lien Xilinx (Pour l'ISE 14.6):

http://www.xilinx.com/products/design-tools/ise-design-suite/index.htm

Lien Xilinx (Pour les versions antérieures veuillez faire attention au système d'exploitation, votre architecture matérielle et le FPGA cible):

(Les informations de compatibilité son sur la page suivante:) (mots clés: xilinx classic(s))

http://www.xilinx.com/tools/classics.htm

=== Procédure pour faire une programmation en volatile: ===

Générer le bitstream, et le charger.

=== Procédure pour faire une programmation en "non"-volatile: ===

Générer le bitstream et l'utiliser pour générer un .mcs qui vous permettra d'inscrire le programme dans la mémoire (E?)PROM.

On remarquera que la programmation en non-volatile est utile pour faire un remise à zéro et recharger le contenu de l'(E?)PROM, mais semble être sensible au débranchement de l'adaptateur d'alimentation de la carte.

=== Exemple de programmation: ===

Voir le lien digilent pour ceci dans cette annexe.

Fichier:P34 2013 2014 DSC 0025 PLL non verrouillage semaine 10.jpg

2014-04-13T19:51:42Z

Jvaessen :

Fichier:P34 2013 2014 DSC 0027 montage realisee semaine 10.jpg

2014-04-13T19:43:35Z

Jvaessen :

Modem pour le numérique

2014-04-13T19:36:51Z

Jvaessen : /* 9éme semaine: (du 28/03/2014 au 03/04/2014) */

= Modulateur et démodulateur pour communications numériques =

== Cahier des charges ==

=== Présentation générale du projet ===

Dans le cadre des TPs d'électronique et de transmission RF, nous avons découvert qu'il existe plusieurs modes de modulation, pour transmettre un signal modulant.

Celles vues en TP au S7 sont la modulation en amplitude, en fréquence, en phase, en BPSK et en QPSK.

Or les modulations en phase, en fréquence et en amplitude étant celles les plus connues, la modulation en QAM (Modulation d'Amplitude en Quadrature) est quant à elle moins connue, mais tout aussi utilisées:

-pour la TNT en 64 QAM (en France).

[[Fichier:P34_2013_2014_64qam.jpg|300px|thumb|center|Exemple de constellation 64QAM.]]

-pour le WiFi en 64-QAM ou 256-QAM (à vérifier).

Or ces deux dernières étant peu représentées au niveau des travaux pratiques, ce projet permettra de fournir un peu plus de pratique sur les modulations de type QAM (en diagramme I/Q) dans le domaine des radiofréquences (~800MHz).

(Le nombre devant le QAM indique le nombre de points dans le diagramme I/Q qu'on appelle aussi constellation)

On se réserve le droit de faire '''évoluer''' le cahier des charges a posteriori, si certaines contraintes étaient amenées à évoluer ou se préciser.

=== Objectif et intérêt du projet ===

Pour cela, on nous a fourni des modules commerciaux Mini-circuit pouvant travailler dans les radios-fréquences.

Ceux-ci permettront de mettre en place une grande partie de la chaine de transmission (voir schéma de la chaine de transmission).

[[Fichier:P34_2013_2014_Chaine_modulation.PNG|300px|thumb|center|Modulation.]]

[[Fichier:P34_2013_2014_Chaine_demodulation.PNG|300px|thumb|center|Demodulation.]]

On a tout d'abord à mettre en place une carte FPGA et/ou un dispositif permettant d'envoyer un flux de données numériques continuellement pour pouvoir visualiser le diagramme I/Q (mise en valeur du diagramme I/Q et voir même un diagramme un peu plus complexe que le BPSK ou le QPSK).

Le canal de transmission qui sera un simple fil électrique, mais pourra devenir une antenne réceptrice et émettrice si le temps imparti le permet (mise en valeur du et mesure du Bit Error Rate qui sera bien sûr différent suivant le canal de transmission).

Du côté réception ,après démodulation du signal, une remise en forme et une interprétation des données seront réalisées, celle-ci dépendra bien entendu de la provenance du flux de données (constater le succès ou l'échec d'un envoi de données).

Enfin si le temps le permets on pourra mettre en une place un système de codage de l'information avec par exemple un codage redondant permettant de corrigé l'erreur (À définir, on pourra faire constater l'efficacité d'une méthode de codage au choix).

=== Étapes/Déroulement du projet ===

De même que pour le cahier des charges, il se peut que les étapes diffèrent plus ou moins, en fonction des disponibilités, matérielles et contraintes.

==== => Caractérisation des blocs Mini-circuits et épluchage des documentations techniques====
Avant de les utiliser dans la chaine de transmission, nous avons à faire une caractérisation des blocs fournis:

-la caractérisation du VCO.

-l'étude des possibilités offerte par le modulateur (cela déterminera le nombre de points possible dans la constellation, ie savoir si l'on peut aller au-delà de la QPSK).

-la caractérisation des mélangeurs (Mixer), leurs facteurs réels de multiplication.

==== => Utilisation et exploitation des caractérisations ====
On pourra ensuite trouver les paramètres pour régler correctement dans notre chaine de transmission certains de nos sous-systèmes comme la boucle à verrouillage de phase.

==== => Génération d'un flux des données numériques ====
Comme dit précédemment, l'idéal et d'avoir un flux de données numériques transmis en permanence.
Pour cela plusieurs solutions s'offre à nous, on pourra utiliser un montage générateur pseudo aléatoire (un circuit que l'on a fait l'année dernière en Conception de Circuit Électronique).
On pourra "émuler" ce montage avec un Arduino, ou bien même le faire au moyen de la Nanoboard.
On pourra aussi transmettre des chaines de caractère en continu.

==== => Test de la chaine ====
Une fois les étapes précédentes réalisées, on pourra passer au test de la chaine de transmission. Il faudra vérifier le bon fonctionnement en aval, dedans (boucle a verrouillage de phase), et en amont de la chaine de transmission.

==== => Première mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.
Il est possible que la conception d'un dispositif soit nécessaire que ce soit pour les deux mesures du B.E.R..

==== => Antennes ====
Si toutes les étapes précédentes sont satisfaites, on pourra alors faire un canal de transmission plus intéressant, à savoir l'air.
Nous passerons alors à la conception des antennes, émettrice et réceptrice.

==== => Deuxième mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.

==== => Codage de l'information et correction d'erreur ====
En toute fin de ce projet, on pourra même mettre deux dispositifs en aval et en amont de la chaine de transmission.
On réalisera alors un codeur et un décodeur permettant de faire de la détection/correction d'erreur.

==== => Mise en place d'outil de débogage (tout au long)====
La mise en place de simples outils de débogage et primordiale, ceux-ci permettront de vérifier le bon fonctionnement de la chaine.

==== => Proposition d'un sujet de TP (tout au long) ====
Il se trouve que lors du déroulement du projet, on pourra être amené à se poser des questions au niveau des réglages de la chaine de transmission.
Or il est fort probable que les élèves qui travailleront sur ce TP pourront alors se poser les mêmes questions.
C'est pour cela qui sera judicieux de prendre soin de noter les problématiques rencontrées et de donner un certain fil de développement pour venir à bout de la problématique posée.
Ce qui reviendra à proposer des axes/questions sur les manipulations de cette maquette de TP.

== Note valable pour toutes les semaines ==

'''[[Si un point vous semble imprécis, veuillez vous reportez aux détails fournit en annexe.]]'''

== 1éme semaine: (du 27/01/2014 au 01/02/2014) ==

Séance du 05/02/2014 :

Pour bien comprendre les différentes choses à réaliser, on a refait les manipulations vues en TP. On a, pour cela utiliser la maquette didactique TIMS pour générer différent type de modulation:

-la modulation en 4,8,16PSK (on obtient une constellation en forme de cercle).

-La modulation en 4,8,16QAM (on obtient une constellation avec un carré, ou deux: de différentes tailles).

On a très vite dégagé la nécessité de réaliser un montage générateur de tous les mots numériques possibles.
On a donc fait un programme sur arduino qui équivaut au générateur pseudo aléatoire.
Celui-ci est directement inspiré du montage que l'on a réalisé l'année dernière en conception de circuit électronique.

Séance du 06/02/2014 :

Lors de cette séance on a exploré toute les possibilités concernant la communication entre la maquette/carte car cela pour avoir une influecnce non négligeable sur le choix de la carte F.P.G.A. et du design de la maquette.

On a donc aussi fait des recherches concernant les possibilités de communications et les bloc I.P. (Intellectual Properties) permettant de programmer un F.P.G.A.

Et enfin, on a eu une discussion avec un responsable technique pour ce qui de la C.E.M. (Compatibilité Electro-Magnétique)

== 2éme semaine: (du 03/02/2014 au 08/02/2014) ==

Réflexion sur les possibilités possibles et offertes par le sujet pour ce qui est des parties de communications entre la maquette en interne et de son environnement.

[[Fichier:P34_2013_2014_schéma_principe_carte_semaine_2.PNG|300px|thumb|center|Maquette en interne/externe.]]

N'ayant jamais utilisé d'autre carte que la Nanoboard, on s'est attelé à faire des recherches sur la manière de procéder pour programmer une carte F.P.G.A., il se trouve que chaque carte de développement à ses propes manières pour être programmé.

On a pris le soin de notez toutes les questions concernant le F.P.G.A. pour un intervenant industrielle qui assura un cours la semaine prochaine.

== 3éme semaine: (du 10/02/2014 au 15/02/2014) ==

Ayant les oscillateurs commandables en tension, on a pu commencer à faire une manipulation avec les composants Mini Circuit.

Mais après un problème suite à une manipulation l'un des VCOs ne fonctionne plus.

Ce qui nous amène à penser qu'il sera judicieux de prévoir une alimentation au niveau de la carte.

Celle-ci devra être inférieure ou égale à la tension maximale d'alimentation du composant (ceux-ci étant très sensible).

Questions/Réponses:

Comment fait-on pour programmer une carte F.P.G.A. est-ce que la programmation se fait "in situe" ? (in situe : c'est à dire sur la carte elle même)
Oui, c'est ce qui est utilisé, via une câble JTAG.

Est-ce possible faire une interface USB pour permettre à un ordinateur de communiquer avec la maquette/carte via un F.P.G.A. ? Oui.

Est-ce que la gestion de l'interface Ethernet est envisageable ? Oui.

Pour une communication en protocole UDP avec un ordinateur via une liaison Ethernet, est-ce qu'il y a d'autre façon que d'utiliser un Soft Core ?

Oui, il existe aussi bien en Software, qu'en Hardware.

== 4éme semaine: (du 17/02/2014 au 22/02/2014) ==

On a donc repris l'idée de la 2éme semaine.

Après avoir mis en place un cahier des charges au niveau des qualités, bande passante minimale.

Nous avons fait des recherches sur les composants à utiliser (ie CAN, CAN, ...)

Ce qui nous a permis après une édition rapide de schéma électrique (schematic) d'avoir une idée du nombre de pins dont nous aurons besoin sur une carte FPGA afin de réaliser le projet.

Après prospection, il se trouve que nous nous dirigerions vers la carte Digilent Spartan 3, dont l'école était déjà en possession.

Donc nous nous sommes attelés à faire des recherches et des essais sur cette carte et pour notamment trouver un moyen de la faire fonctionner.

== 5éme semaine: (du 03/03/2014 au 08/03/2014) ==

Tout d'abord, après plusieurs heures de recherches et d'essai infructueux, on a fini par trouver les drivers pour le câble USB diligent.

Et donc ainsi avoir un fonctionnement de la communication via le câble JTAG plus propice au fonctionnement de la carte.

On a pu enfin se conforter sur une partie des composants et des dimensionnements pour certains d'entre eux (valeur de résistance,capacité...)

Schématics: Édition de multiple bibliothèque pour Altium, intégrant à la fois schématics et leur empreinte PCB associés.

(On a pu constater qu'un interface 3v3 5v n'est pas forcement nécessaire pour assurer le bon fonctionnement entre deux cartes avec des tensions d'alimentation différentes.)

== 6éme semaine: (du 10/03/2014 au 15/03/2014) ==

On a pu enfin se conforter sur l'ensemble des composants et des choix de régulateur et utilisation d'autre diode Zener.

On trouvera le schéma intégrale avec les bibliothèques nécessaires dans la semaine 5.

Cette semaine à été dédié à l'envoie de la commande des composants au sein du magasin de l'école et du fournisseur.

Après envoi de la commande, il se trouve que le projet a changé d'objectif principal.

Il est maintenant prioritaire de réaliser un code VHDL capable d'évaluer la vitesse de transmission numérique du côté récepteur.

== 7éme semaine: (du 17/03/2014 au 22/03/2014) ==

Pour cette semaine, on s'est concentré sur la réalisation d'un générateur pseudo aléatoire en interne au FPGA.

On réalisera une échelle de résistance afin de réaliser une conversion numérique analogique afin de l'envoyer sur la chaine de transmission.

Ce code de "base" nous permettra de réaliser un flux de données fictif pour obtenir toutes les combinaisons récupérant le résultat du bus.

[[MédiaP34_2013_2014_gene_pseudo_19_03_2014_6_semaine_7.zip|Archive contenant le projet ISE Xilinx.]]

[[Fichier:P34_2013_2014_rtl_semaine_7.PNG|300px|thumb|center|extrait du schéma RTL, on peut y voir clairement les inférences de Xilinx.]]

Ce schéma a deux entrées et une sortie, une entrée d'initialisation, une horloge et une sortie pour la trame en pseudo aléatoire.

On fera l'essaie sur la carte lors de la semaine suivante.

== 8éme semaine: (du 24/03/2014 au 26/03/2014) ==

Aprés le premier test, on pourrait penser que l'on récupère du bruit en sortie de la carte:

[[Fichier:P34_2013_2014_DSC_0024_1_probleme_d_overshoot_semaine_8.jpg|300px|thumb|center|Overshoot.]]

Pour pouvoir remédier à ce problème on a fait une pré-division de l'horloge

[[Fichier:P34_2013_2014_DSC_0037_1_div_freq_semaine_8.jpg|300px|thumb|center|Overshoot après division.]]

[[Fichier:P34_2013_2014_DSC_0039_1_div_freq_zoom_semaine_8.jpg|300px|thumb|center|Overshoot après division (Zoom).]]

Archive contenant toutes les modifications:

[[Média:P34_2013_2014_gene_pseudo_26_03_2014_2_semaine_8.zip|VHDL Semaine 8.]]

On a trouvé un moyen de faire un CNA facilement, via une "échelle dit R-2R". [[http://www.uchobby.com/index.php/2008/01/08/arduino-audio-dac-options/|Pour le réseau R 2R.]]

Il faut encore modifier le VHDL pour pouvoir l'exploiter et ainsi générer une constellation.

== 9éme semaine: (du 28/03/2014 au 03/04/2014) ==

On a pris donc le soin de modifier le VHDL:

[[Média:P34_2013_2014_gene_pseudo_31_03_2014_1_semaine_9.zip|VHDL semaine 9]]

Ce VHDL à été mis à jour, avec deux entrées (initialisation et une horloge) et un bus de sortie, avec les trames pseudo-aléatoire.

On envoie ces signaux sur deux C.N.A.s (4 bits chacun) pour générer deux signaux I et Q, on peut voir une constellation se dessiner en mode X-Y.

[[Fichier:P34_2013_2014_DSC_0072_1_Montage_entier_4qam_semaine_9.jpg|300px|thumb|center|Montage avec constellations 4QAM.]]

D'autre constellations réalisées sont disponibles en annexe. On peut monter jusqu'à une constellation de 256 points (2^4*2^4).

On a réalisé le montage complet de toute la chaine de transmission. Il se trouve que la Boucle à Verrouillage de Phase (ou appellée PLL, Phase Loop Locker) ne se verrouille pas sur la porteuse du signal que l'on souhaite récupéré, de ce fait on ne peut pas récupérer les signaux I et Q.

== 10éme semaine: (rédaction en cours) (du 07/04/2014 au 10/04/2014) ==

= Annexes =

== Annexe A: Détails techniques des semaines ==

=== 1éme semaine: (du 27/01/2014 au 01/02/2014) ===

Après on a réfléchi sur la potentielle conception/utilisation d'une carte FPGA.
Il sera judicieux de ne pas se précipiter sur le schéma et la conception/utilisation d'une carte FPGA, sans avoir, au préalable fait le VHDL et le testez avec un banc de test virtuel.
L'intérêt et de mettre en valeur la nécessité ou non de certains signaux pour le schéma de la carte.
On va mettre en oeuvre les connaissances acquises au S7 en VHDL (en TP de Circuit Numérique Programmble).

Pour ce qui est de l'Arduino, on a répondu aux interrogations suivantes (certaines de ces questions paraissent triviales, mais on préfère éviter les surprises):

Quelle est la vitesse maximale de la communication série de l'Arduino ?
-115200bauds

Est-ce que, un programme de type "Analog Write" est-il une vraie sortie analogique ?

-Non, c'est juste une PWM. Elle sera exploitable pour faire les signales I/Q mais très contraignantes, car il faudra filtré le signal, et ce sera beaucoup trop lent (du au fait que la modulation est faite au alentour de 850Mhz), le FPGA sera un passage obligé cela ouvrira les portes d'un plus grand débit.

==== Manipulation réalisée sur la maquette TIMS : ====

On a fait un des montages présenté dans l'ouvrage "Volume D1 Fundamental Digital Experiments" dans le but de visualiser l’objectif à atteindre.

On obtient la constellation suivante (16QAM):

[[Fichier:P34_2013_2014_constelation_tims_semaine_1.PNG|300px|thumb|center|Constellation visualisé en mode X-Y.]]

Ce qui correspond à deux signaux en visualisation temporelle de cette forme :

[[Fichier:P34_2013_2014_constelation_temporelle_tims_semaine_1.PNG|300px|thumb|center|Signaux I et Q. (Image très flouté, à remplacer)]]

On pourra facilement obtenir le même résultat en générant un bus de trame pseudo aléatoire et en l'injectant dans un C.N.A. (Conversion Numérique Analogique)

==== Code Arduino réalisé: ====

[[Fichier:P34_2013_2014_schema_electronique_generateur_pseudo_aleatoire.png|300px|thumb|center|Schéma électronique du générateur pseudo aléatoire.]]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_chrono_simule.PNG|300px|thumb|center|Résultat de la simulation du générateur pseudo aléatoire (on a eu la même chose en pratique).]]

[code]
/*A peut être supprimer*/
#include <avr/io.h>
#include <util/delay.h>

void output_init(void){
DDRB |= 0x02; // PIN 8,9 sont les deux sorties.
}

int main(void){
int r1=1,r2=0,r3=0,r4=0,r5=0,retard=0;
PORTB=0x00;
while(1)
{
r5=r4;//chaque affectation représente une recopie de la bascule sur le "front montant", ici c'est simplement l’exécution du code.
r4=r3;
r3=r2;
r2=r1;
r1=r4^r5;
PORTB=0x01*r1+0x02*retard;//écriture des signaux
_delay_ms(10);//le "front montant", ce qui permet de faire un genre d'horloge.
retard=r5;//déphasage du signal
}
return 0;
}
[/code]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_arduino.jpg|300px|thumb|center|Resultat avec le generateur pseudo aléatoire "émuler" avec l'Arduino.]]

Comparaison carte réelle/résultat Arduino:

C'était exactement les signaux attendus (même s'il y un décalage a par rapport à l'original).

On aura bien pour une QPSK (4PSK) tous les couples (ie 00,01,11 et 10).

À propos de l'arduino, on pourra envisager une amélioration pour générer une séquence plus longue:

-il faudra simplement utiliser un tableau d'entier.

-paramétrer sa taille avec un N par exemple.

-N correspondra à la taille de séquence de longueur 2^N.

Voir la section "Code Arduino réalisé" en annexe B dans la semaine correspondante.

==== Possibilités de communications: ====

Exploration des possibilités de communication entre le PC et la carte en amont:

=====-> Ethernet: =====

*+ Vitesse de transmission (~10M-100M-G)bauds

*- La gestion du flux de données doit être faite par un microcontrôleur (celui-ci pourra être implémenté un bloc I.P. à l'intérieur du FPGA)

-> - Haute consommation de CLB du FPGA.

=====-> SPI (communication série): =====

*- Vitesse de transmission

-> Arduino capable de communiquer jusqu'a 115200 bauds

-> D'après certaines discussions on pourrait « pousser » au-delà : voir le lien des sujets Raspberry Pi.

=====-> I2C : =====

Communication abandonné, ce n'est pas une priorité.

==== À propos des blocs I.P.: ====

En consultant les ordinateurs et en s'appuyant des TPs de CNP, on constate que les blocs suivants existent:

- Xilinx Microblaze/Xilinx Power PC ("µP FPGA")

-> Est-ce possible d'utiliser ces blocs I.P. pour programmer un FPGA sur une carte autre que la Nanoboard ? Comment ?

- EMACx (Ethernet Media Acess Control)(:lien physique entre processeurs et "standart Physical Layer device IEEE802.3")

===== Conception de la carte: =====

L'idéal est de se documenter sur la Compatibilité électromagnétique.

=== 2éme semaine: (du 03/02/2014 au 08/02/2014) ===

(Rien en annexe.)

=== 3éme semaine: (du 10/02/2014 au 15/02/2014) ===

Lors de cette semaine, après avoir eu le problème de manipulation, nous avons pus prendre connaissance d'un certain montage qui s’avéra utile pour la conception de la carte/maquette.

[[Fichier:P34_2013_2014_schéma_limiteur_de_courant_semaine_3.PNG|300px|thumb|center|Schéma limiteur de courant.]]

On remarquera que ce montage se retrouve dans la partie "typical application" de la documentation technique du 7805.

=== 4éme semaine: (du 17/02/2014 au 22/02/2014) ===

On souhaite pouvoir réaliser une communication unidirectionnel ou même transmettre un signal audio ce qui nous contraint à une bande passante minimal de 48kHz, on prendra 200kHz (Pour être bien au delà de la conditions du théorème de Shannon): le but serait donc de branchez par exemple une source audio quelconque puis de la transmettre à travers la maquette et de la recomposer en fin de chaine.

Après édition rapide du schématique on en dégage qu'il nous faudra un minimum d'environ 50 entrées/sorties. Mais ceci ce nombre sera très probablement revue à la hausse lors de prochaine séance.

Voici la carte que l'on utilisera dans la suite du projet:

[[Fichier:P34_2013_2014_S3BOARD-top-400_semaine_4.gif|300px|thumb|center|Digilent Spartan 3.]]

=== 5éme semaine: (du 03/03/2014 au 08/03/2014) ===

Lien vers le Design complet avec les librairies incluses (on remarquera qu'il serait judicieux d’installer toutes les librairies avant d’essayer d'ouvrir le schéma)

A notez aussi que l'on trouvera des reliques de feuilles Excel permettant de trouver rapidement des ratios dans la série E12.

[[Média:P34_2013_2014_Design_pcb_plus_librairies_semaine_5_6.zip|Schéma + Bibliothèques.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.pdf|Schéma en PDF.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.png|Schéma au format A2.]]

=== 6éme semaine: (du 10/03/2014 au 15/03/2014) ===

(Rien en annexe.)

=== 7éme semaine: (du 17/03/2014 au 22/03/2014) ===

(Rien en annexe.)

=== 8éme semaine: (du 24/03/2014 au 26/03/2014) ===

(Rien en annexe.)

=== 9éme semaine: (du 28/03/2014 au 03/04/2014) ===

[[Fichier:P34_2013_2014_DSC_0061_1_r_2r_semaine_9.jpg|center|thumb|300px|Le réseau R-2R.]]

[[Fichier:P34_2013_2014_DSC_0062_1_4QAM_semaine_9.jpg|center|thumb|300px|4QAM.]]

[[Fichier:P34_2013_2014_DSC_0066_1_16QAM_semaine_9.jpg|center|thumb|300px|16QAM.]]

[[Fichier:P34_2013_2014_DSC_0069_1_64QAM_semaine_9.jpg|center|thumb|300px|64QAM.]]

Pas de photos pour la constellation à 256 points, mais elle a été réalisée.

Pour ce qui est du montage, malgré que la P.L.L., on a un signal d'erreur après filtrage :

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Chaine 1: Vtune (commande du V.C.O.)/Chaine 2: "erreur" de commande]]

Ce qui mets en valeur immédiatement deux problèmes majeurs:

La chaine fonctionne sur le papier, mais lors de sa mise en pratique, il faut penser à mettre une tension d'offset et aussi réaliser une amplification de l'erreur pour avoir des grandeur de commande adapté au Vtune du V.C.O..

On propose l'amélioration suivante (qui sera réalisé à la prochaine séance):

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Proposition de voie d'amélioration.]]

On remarquera que les valeurs des résistances et des capacité on était choisit pour permettre un fonctionnement correct des A.O. (Amplificateur Opérationnel), mais pas pour ce qui de l'asservissement de la boucle par manque de temps.

A la fin de cette, on a eu à démonter le montage à cause de contraintes concernant les mini-circuits (car utilisé en travaux pratiques).

=== 10éme semaine: (rédaction en cours) (du 07/04/2014 au 10/04/2014) ===

== Annexe B: Digilent Spartan 3 ==

=== Procédure pour faire fonctionner la carte Digilent Spartan 3: ===

Ne connectez pas de connecteur JTAG pendant les installations. Redémarrez après chaque installation.

Tout d'abord, il faut savoir que le l'ISE Webpack 14.6 fonctionne avec la carte (n'utilisez pas la 14.7, elle ne supporte pas la génération spartan 3 !):

Installez donc l'ISE WebPack 14.6 (ou antérieur à condition que celle-ci soit supérieur à la 7.1i (d'aprés leur documentation))

(voir lien utile sur Xilinx)

Une fois l'installation de l'ISE terminé, faites en sorte d'avoir celui que soit opérationnel (la licence est gratuite !).

Installez la "library" ADEPT 2.3 voir le lien utile.

Après vous n'avez plus qu'a utilisez ISE Xilinx normalement et vous serez capable de reconnaitre la carte via la liaison JTAG, et de le programmer.

=== Liens utiles: ===

Lien constructeur/vendeur (avec ressources utiles en bas de la page):

http://www.digilentinc.com/Products/Detail.cfm?Prod=S3BOARD

Lien "Library" pour le câble USB digilent:

http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,66,69&Prod=ADEPT

Lien Xilinx (Pour l'ISE 14.6):

http://www.xilinx.com/products/design-tools/ise-design-suite/index.htm

Lien Xilinx (Pour les versions antérieures veuillez faire attention au système d'exploitation, votre architecture matérielle et le FPGA cible):

(Les informations de compatibilité son sur la page suivante:) (mots clés: xilinx classic(s))

http://www.xilinx.com/tools/classics.htm

=== Procédure pour faire une programmation en volatile: ===

Générer le bitstream, et le charger.

=== Procédure pour faire une programmation en "non"-volatile: ===

Générer le bitstream et l'utiliser pour générer un .mcs qui vous permettra d'inscrire le programme dans la mémoire (E?)PROM.

On remarquera que la programmation en non-volatile est utile pour faire un remise à zéro et recharger le contenu de l'(E?)PROM, mais semble être sensible au débranchement de l'adaptateur d'alimentation de la carte.

=== Exemple de programmation: ===

Voir le lien digilent pour ceci dans cette annexe.

Modem pour le numérique

2014-04-13T19:34:58Z

Jvaessen : /* 9éme semaine: (rédaction en cours) (du 28/03/2014 au 03/04/2014) */

= Modulateur et démodulateur pour communications numériques =

== Cahier des charges ==

=== Présentation générale du projet ===

Dans le cadre des TPs d'électronique et de transmission RF, nous avons découvert qu'il existe plusieurs modes de modulation, pour transmettre un signal modulant.

Celles vues en TP au S7 sont la modulation en amplitude, en fréquence, en phase, en BPSK et en QPSK.

Or les modulations en phase, en fréquence et en amplitude étant celles les plus connues, la modulation en QAM (Modulation d'Amplitude en Quadrature) est quant à elle moins connue, mais tout aussi utilisées:

-pour la TNT en 64 QAM (en France).

[[Fichier:P34_2013_2014_64qam.jpg|300px|thumb|center|Exemple de constellation 64QAM.]]

-pour le WiFi en 64-QAM ou 256-QAM (à vérifier).

Or ces deux dernières étant peu représentées au niveau des travaux pratiques, ce projet permettra de fournir un peu plus de pratique sur les modulations de type QAM (en diagramme I/Q) dans le domaine des radiofréquences (~800MHz).

(Le nombre devant le QAM indique le nombre de points dans le diagramme I/Q qu'on appelle aussi constellation)

On se réserve le droit de faire '''évoluer''' le cahier des charges a posteriori, si certaines contraintes étaient amenées à évoluer ou se préciser.

=== Objectif et intérêt du projet ===

Pour cela, on nous a fourni des modules commerciaux Mini-circuit pouvant travailler dans les radios-fréquences.

Ceux-ci permettront de mettre en place une grande partie de la chaine de transmission (voir schéma de la chaine de transmission).

[[Fichier:P34_2013_2014_Chaine_modulation.PNG|300px|thumb|center|Modulation.]]

[[Fichier:P34_2013_2014_Chaine_demodulation.PNG|300px|thumb|center|Demodulation.]]

On a tout d'abord à mettre en place une carte FPGA et/ou un dispositif permettant d'envoyer un flux de données numériques continuellement pour pouvoir visualiser le diagramme I/Q (mise en valeur du diagramme I/Q et voir même un diagramme un peu plus complexe que le BPSK ou le QPSK).

Le canal de transmission qui sera un simple fil électrique, mais pourra devenir une antenne réceptrice et émettrice si le temps imparti le permet (mise en valeur du et mesure du Bit Error Rate qui sera bien sûr différent suivant le canal de transmission).

Du côté réception ,après démodulation du signal, une remise en forme et une interprétation des données seront réalisées, celle-ci dépendra bien entendu de la provenance du flux de données (constater le succès ou l'échec d'un envoi de données).

Enfin si le temps le permets on pourra mettre en une place un système de codage de l'information avec par exemple un codage redondant permettant de corrigé l'erreur (À définir, on pourra faire constater l'efficacité d'une méthode de codage au choix).

=== Étapes/Déroulement du projet ===

De même que pour le cahier des charges, il se peut que les étapes diffèrent plus ou moins, en fonction des disponibilités, matérielles et contraintes.

==== => Caractérisation des blocs Mini-circuits et épluchage des documentations techniques====
Avant de les utiliser dans la chaine de transmission, nous avons à faire une caractérisation des blocs fournis:

-la caractérisation du VCO.

-l'étude des possibilités offerte par le modulateur (cela déterminera le nombre de points possible dans la constellation, ie savoir si l'on peut aller au-delà de la QPSK).

-la caractérisation des mélangeurs (Mixer), leurs facteurs réels de multiplication.

==== => Utilisation et exploitation des caractérisations ====
On pourra ensuite trouver les paramètres pour régler correctement dans notre chaine de transmission certains de nos sous-systèmes comme la boucle à verrouillage de phase.

==== => Génération d'un flux des données numériques ====
Comme dit précédemment, l'idéal et d'avoir un flux de données numériques transmis en permanence.
Pour cela plusieurs solutions s'offre à nous, on pourra utiliser un montage générateur pseudo aléatoire (un circuit que l'on a fait l'année dernière en Conception de Circuit Électronique).
On pourra "émuler" ce montage avec un Arduino, ou bien même le faire au moyen de la Nanoboard.
On pourra aussi transmettre des chaines de caractère en continu.

==== => Test de la chaine ====
Une fois les étapes précédentes réalisées, on pourra passer au test de la chaine de transmission. Il faudra vérifier le bon fonctionnement en aval, dedans (boucle a verrouillage de phase), et en amont de la chaine de transmission.

==== => Première mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.
Il est possible que la conception d'un dispositif soit nécessaire que ce soit pour les deux mesures du B.E.R..

==== => Antennes ====
Si toutes les étapes précédentes sont satisfaites, on pourra alors faire un canal de transmission plus intéressant, à savoir l'air.
Nous passerons alors à la conception des antennes, émettrice et réceptrice.

==== => Deuxième mesure du Bit Error Rate ====
Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.

==== => Codage de l'information et correction d'erreur ====
En toute fin de ce projet, on pourra même mettre deux dispositifs en aval et en amont de la chaine de transmission.
On réalisera alors un codeur et un décodeur permettant de faire de la détection/correction d'erreur.

==== => Mise en place d'outil de débogage (tout au long)====
La mise en place de simples outils de débogage et primordiale, ceux-ci permettront de vérifier le bon fonctionnement de la chaine.

==== => Proposition d'un sujet de TP (tout au long) ====
Il se trouve que lors du déroulement du projet, on pourra être amené à se poser des questions au niveau des réglages de la chaine de transmission.
Or il est fort probable que les élèves qui travailleront sur ce TP pourront alors se poser les mêmes questions.
C'est pour cela qui sera judicieux de prendre soin de noter les problématiques rencontrées et de donner un certain fil de développement pour venir à bout de la problématique posée.
Ce qui reviendra à proposer des axes/questions sur les manipulations de cette maquette de TP.

== Note valable pour toutes les semaines ==

'''[[Si un point vous semble imprécis, veuillez vous reportez aux détails fournit en annexe.]]'''

== 1éme semaine: (du 27/01/2014 au 01/02/2014) ==

Séance du 05/02/2014 :

Pour bien comprendre les différentes choses à réaliser, on a refait les manipulations vues en TP. On a, pour cela utiliser la maquette didactique TIMS pour générer différent type de modulation:

-la modulation en 4,8,16PSK (on obtient une constellation en forme de cercle).

-La modulation en 4,8,16QAM (on obtient une constellation avec un carré, ou deux: de différentes tailles).

On a très vite dégagé la nécessité de réaliser un montage générateur de tous les mots numériques possibles.
On a donc fait un programme sur arduino qui équivaut au générateur pseudo aléatoire.
Celui-ci est directement inspiré du montage que l'on a réalisé l'année dernière en conception de circuit électronique.

Séance du 06/02/2014 :

Lors de cette séance on a exploré toute les possibilités concernant la communication entre la maquette/carte car cela pour avoir une influecnce non négligeable sur le choix de la carte F.P.G.A. et du design de la maquette.

On a donc aussi fait des recherches concernant les possibilités de communications et les bloc I.P. (Intellectual Properties) permettant de programmer un F.P.G.A.

Et enfin, on a eu une discussion avec un responsable technique pour ce qui de la C.E.M. (Compatibilité Electro-Magnétique)

== 2éme semaine: (du 03/02/2014 au 08/02/2014) ==

Réflexion sur les possibilités possibles et offertes par le sujet pour ce qui est des parties de communications entre la maquette en interne et de son environnement.

[[Fichier:P34_2013_2014_schéma_principe_carte_semaine_2.PNG|300px|thumb|center|Maquette en interne/externe.]]

N'ayant jamais utilisé d'autre carte que la Nanoboard, on s'est attelé à faire des recherches sur la manière de procéder pour programmer une carte F.P.G.A., il se trouve que chaque carte de développement à ses propes manières pour être programmé.

On a pris le soin de notez toutes les questions concernant le F.P.G.A. pour un intervenant industrielle qui assura un cours la semaine prochaine.

== 3éme semaine: (du 10/02/2014 au 15/02/2014) ==

Ayant les oscillateurs commandables en tension, on a pu commencer à faire une manipulation avec les composants Mini Circuit.

Mais après un problème suite à une manipulation l'un des VCOs ne fonctionne plus.

Ce qui nous amène à penser qu'il sera judicieux de prévoir une alimentation au niveau de la carte.

Celle-ci devra être inférieure ou égale à la tension maximale d'alimentation du composant (ceux-ci étant très sensible).

Questions/Réponses:

Comment fait-on pour programmer une carte F.P.G.A. est-ce que la programmation se fait "in situe" ? (in situe : c'est à dire sur la carte elle même)
Oui, c'est ce qui est utilisé, via une câble JTAG.

Est-ce possible faire une interface USB pour permettre à un ordinateur de communiquer avec la maquette/carte via un F.P.G.A. ? Oui.

Est-ce que la gestion de l'interface Ethernet est envisageable ? Oui.

Pour une communication en protocole UDP avec un ordinateur via une liaison Ethernet, est-ce qu'il y a d'autre façon que d'utiliser un Soft Core ?

Oui, il existe aussi bien en Software, qu'en Hardware.

== 4éme semaine: (du 17/02/2014 au 22/02/2014) ==

On a donc repris l'idée de la 2éme semaine.

Après avoir mis en place un cahier des charges au niveau des qualités, bande passante minimale.

Nous avons fait des recherches sur les composants à utiliser (ie CAN, CAN, ...)

Ce qui nous a permis après une édition rapide de schéma électrique (schematic) d'avoir une idée du nombre de pins dont nous aurons besoin sur une carte FPGA afin de réaliser le projet.

Après prospection, il se trouve que nous nous dirigerions vers la carte Digilent Spartan 3, dont l'école était déjà en possession.

Donc nous nous sommes attelés à faire des recherches et des essais sur cette carte et pour notamment trouver un moyen de la faire fonctionner.

== 5éme semaine: (du 03/03/2014 au 08/03/2014) ==

Tout d'abord, après plusieurs heures de recherches et d'essai infructueux, on a fini par trouver les drivers pour le câble USB diligent.

Et donc ainsi avoir un fonctionnement de la communication via le câble JTAG plus propice au fonctionnement de la carte.

On a pu enfin se conforter sur une partie des composants et des dimensionnements pour certains d'entre eux (valeur de résistance,capacité...)

Schématics: Édition de multiple bibliothèque pour Altium, intégrant à la fois schématics et leur empreinte PCB associés.

(On a pu constater qu'un interface 3v3 5v n'est pas forcement nécessaire pour assurer le bon fonctionnement entre deux cartes avec des tensions d'alimentation différentes.)

== 6éme semaine: (du 10/03/2014 au 15/03/2014) ==

On a pu enfin se conforter sur l'ensemble des composants et des choix de régulateur et utilisation d'autre diode Zener.

On trouvera le schéma intégrale avec les bibliothèques nécessaires dans la semaine 5.

Cette semaine à été dédié à l'envoie de la commande des composants au sein du magasin de l'école et du fournisseur.

Après envoi de la commande, il se trouve que le projet a changé d'objectif principal.

Il est maintenant prioritaire de réaliser un code VHDL capable d'évaluer la vitesse de transmission numérique du côté récepteur.

== 7éme semaine: (du 17/03/2014 au 22/03/2014) ==

Pour cette semaine, on s'est concentré sur la réalisation d'un générateur pseudo aléatoire en interne au FPGA.

On réalisera une échelle de résistance afin de réaliser une conversion numérique analogique afin de l'envoyer sur la chaine de transmission.

Ce code de "base" nous permettra de réaliser un flux de données fictif pour obtenir toutes les combinaisons récupérant le résultat du bus.

[[MédiaP34_2013_2014_gene_pseudo_19_03_2014_6_semaine_7.zip|Archive contenant le projet ISE Xilinx.]]

[[Fichier:P34_2013_2014_rtl_semaine_7.PNG|300px|thumb|center|extrait du schéma RTL, on peut y voir clairement les inférences de Xilinx.]]

Ce schéma a deux entrées et une sortie, une entrée d'initialisation, une horloge et une sortie pour la trame en pseudo aléatoire.

On fera l'essaie sur la carte lors de la semaine suivante.

== 8éme semaine: (du 24/03/2014 au 26/03/2014) ==

Aprés le premier test, on pourrait penser que l'on récupère du bruit en sortie de la carte:

[[Fichier:P34_2013_2014_DSC_0024_1_probleme_d_overshoot_semaine_8.jpg|300px|thumb|center|Overshoot.]]

Pour pouvoir remédier à ce problème on a fait une pré-division de l'horloge

[[Fichier:P34_2013_2014_DSC_0037_1_div_freq_semaine_8.jpg|300px|thumb|center|Overshoot après division.]]

[[Fichier:P34_2013_2014_DSC_0039_1_div_freq_zoom_semaine_8.jpg|300px|thumb|center|Overshoot après division (Zoom).]]

Archive contenant toutes les modifications:

[[Média:P34_2013_2014_gene_pseudo_26_03_2014_2_semaine_8.zip|VHDL Semaine 8.]]

On a trouvé un moyen de faire un CNA facilement, via une "échelle dit R-2R". [[http://www.uchobby.com/index.php/2008/01/08/arduino-audio-dac-options/|Pour le réseau R 2R.]]

Il faut encore modifier le VHDL pour pouvoir l'exploiter et ainsi générer une constellation.

== 9éme semaine: (du 28/03/2014 au 03/04/2014) ==

On a pris donc le soin de modifier le VHDL:

[[Média:P34_2013_2014_gene_pseudo_31_03_2014_1_semaine_9.zip|VHDL semaine 9]]

Ce VHDL à été mis à jour, avec deux entrées (initialisation et une horloge) et un bus de sortie, avec les trames pseudo-aléatoire.

On envoie ces signaux sur deux C.N.A.s (4 bits chacun) pour générer deux signaux I et Q, on peut voir une constellation se dessiner en mode X-Y.

[[Fichier:P34_2013_2014_DSC_0072_1_Montage_entier_4qam_semaine_9.jpg|300px|thumb|center|Montage avec constellations 4QAM.]]

D'autre constellations réalisées sont disponibles en annexe. On peut monter jusqu'à une constellation de 256 points (2^4*2^4).

On a réalisé le montage complet de toute la chaine de transmission. Il se trouve que la Boucle à Verrouillage de Phase (ou appellée PLL, Phase Loop Locker) ne se verrouille pas sur la porteuse du signal que l'on souhaite récupéré, de ce fait on ne peut pas récupérer les signaux I et Q.

== 10éme semaine: (rédaction en cours) (du 07/04/2014 au 10/04/2014) ==

= Annexes =

== Annexe A: Détails techniques des semaines ==

=== 1éme semaine: (du 27/01/2014 au 01/02/2014) ===

Après on a réfléchi sur la potentielle conception/utilisation d'une carte FPGA.
Il sera judicieux de ne pas se précipiter sur le schéma et la conception/utilisation d'une carte FPGA, sans avoir, au préalable fait le VHDL et le testez avec un banc de test virtuel.
L'intérêt et de mettre en valeur la nécessité ou non de certains signaux pour le schéma de la carte.
On va mettre en oeuvre les connaissances acquises au S7 en VHDL (en TP de Circuit Numérique Programmble).

Pour ce qui est de l'Arduino, on a répondu aux interrogations suivantes (certaines de ces questions paraissent triviales, mais on préfère éviter les surprises):

Quelle est la vitesse maximale de la communication série de l'Arduino ?
-115200bauds

Est-ce que, un programme de type "Analog Write" est-il une vraie sortie analogique ?

-Non, c'est juste une PWM. Elle sera exploitable pour faire les signales I/Q mais très contraignantes, car il faudra filtré le signal, et ce sera beaucoup trop lent (du au fait que la modulation est faite au alentour de 850Mhz), le FPGA sera un passage obligé cela ouvrira les portes d'un plus grand débit.

==== Manipulation réalisée sur la maquette TIMS : ====

On a fait un des montages présenté dans l'ouvrage "Volume D1 Fundamental Digital Experiments" dans le but de visualiser l’objectif à atteindre.

On obtient la constellation suivante (16QAM):

[[Fichier:P34_2013_2014_constelation_tims_semaine_1.PNG|300px|thumb|center|Constellation visualisé en mode X-Y.]]

Ce qui correspond à deux signaux en visualisation temporelle de cette forme :

[[Fichier:P34_2013_2014_constelation_temporelle_tims_semaine_1.PNG|300px|thumb|center|Signaux I et Q. (Image très flouté, à remplacer)]]

On pourra facilement obtenir le même résultat en générant un bus de trame pseudo aléatoire et en l'injectant dans un C.N.A. (Conversion Numérique Analogique)

==== Code Arduino réalisé: ====

[[Fichier:P34_2013_2014_schema_electronique_generateur_pseudo_aleatoire.png|300px|thumb|center|Schéma électronique du générateur pseudo aléatoire.]]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_chrono_simule.PNG|300px|thumb|center|Résultat de la simulation du générateur pseudo aléatoire (on a eu la même chose en pratique).]]

[code]
/*A peut être supprimer*/
#include <avr/io.h>
#include <util/delay.h>

void output_init(void){
DDRB |= 0x02; // PIN 8,9 sont les deux sorties.
}

int main(void){
int r1=1,r2=0,r3=0,r4=0,r5=0,retard=0;
PORTB=0x00;
while(1)
{
r5=r4;//chaque affectation représente une recopie de la bascule sur le "front montant", ici c'est simplement l’exécution du code.
r4=r3;
r3=r2;
r2=r1;
r1=r4^r5;
PORTB=0x01*r1+0x02*retard;//écriture des signaux
_delay_ms(10);//le "front montant", ce qui permet de faire un genre d'horloge.
retard=r5;//déphasage du signal
}
return 0;
}
[/code]

[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_arduino.jpg|300px|thumb|center|Resultat avec le generateur pseudo aléatoire "émuler" avec l'Arduino.]]

Comparaison carte réelle/résultat Arduino:

C'était exactement les signaux attendus (même s'il y un décalage a par rapport à l'original).

On aura bien pour une QPSK (4PSK) tous les couples (ie 00,01,11 et 10).

À propos de l'arduino, on pourra envisager une amélioration pour générer une séquence plus longue:

-il faudra simplement utiliser un tableau d'entier.

-paramétrer sa taille avec un N par exemple.

-N correspondra à la taille de séquence de longueur 2^N.

Voir la section "Code Arduino réalisé" en annexe B dans la semaine correspondante.

==== Possibilités de communications: ====

Exploration des possibilités de communication entre le PC et la carte en amont:

=====-> Ethernet: =====

*+ Vitesse de transmission (~10M-100M-G)bauds

*- La gestion du flux de données doit être faite par un microcontrôleur (celui-ci pourra être implémenté un bloc I.P. à l'intérieur du FPGA)

-> - Haute consommation de CLB du FPGA.

=====-> SPI (communication série): =====

*- Vitesse de transmission

-> Arduino capable de communiquer jusqu'a 115200 bauds

-> D'après certaines discussions on pourrait « pousser » au-delà : voir le lien des sujets Raspberry Pi.

=====-> I2C : =====

Communication abandonné, ce n'est pas une priorité.

==== À propos des blocs I.P.: ====

En consultant les ordinateurs et en s'appuyant des TPs de CNP, on constate que les blocs suivants existent:

- Xilinx Microblaze/Xilinx Power PC ("µP FPGA")

-> Est-ce possible d'utiliser ces blocs I.P. pour programmer un FPGA sur une carte autre que la Nanoboard ? Comment ?

- EMACx (Ethernet Media Acess Control)(:lien physique entre processeurs et "standart Physical Layer device IEEE802.3")

===== Conception de la carte: =====

L'idéal est de se documenter sur la Compatibilité électromagnétique.

=== 2éme semaine: (du 03/02/2014 au 08/02/2014) ===

(Rien en annexe.)

=== 3éme semaine: (du 10/02/2014 au 15/02/2014) ===

Lors de cette semaine, après avoir eu le problème de manipulation, nous avons pus prendre connaissance d'un certain montage qui s’avéra utile pour la conception de la carte/maquette.

[[Fichier:P34_2013_2014_schéma_limiteur_de_courant_semaine_3.PNG|300px|thumb|center|Schéma limiteur de courant.]]

On remarquera que ce montage se retrouve dans la partie "typical application" de la documentation technique du 7805.

=== 4éme semaine: (du 17/02/2014 au 22/02/2014) ===

On souhaite pouvoir réaliser une communication unidirectionnel ou même transmettre un signal audio ce qui nous contraint à une bande passante minimal de 48kHz, on prendra 200kHz (Pour être bien au delà de la conditions du théorème de Shannon): le but serait donc de branchez par exemple une source audio quelconque puis de la transmettre à travers la maquette et de la recomposer en fin de chaine.

Après édition rapide du schématique on en dégage qu'il nous faudra un minimum d'environ 50 entrées/sorties. Mais ceci ce nombre sera très probablement revue à la hausse lors de prochaine séance.

Voici la carte que l'on utilisera dans la suite du projet:

[[Fichier:P34_2013_2014_S3BOARD-top-400_semaine_4.gif|300px|thumb|center|Digilent Spartan 3.]]

=== 5éme semaine: (du 03/03/2014 au 08/03/2014) ===

Lien vers le Design complet avec les librairies incluses (on remarquera qu'il serait judicieux d’installer toutes les librairies avant d’essayer d'ouvrir le schéma)

A notez aussi que l'on trouvera des reliques de feuilles Excel permettant de trouver rapidement des ratios dans la série E12.

[[Média:P34_2013_2014_Design_pcb_plus_librairies_semaine_5_6.zip|Schéma + Bibliothèques.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.pdf|Schéma en PDF.]]

[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.png|Schéma au format A2.]]

=== 6éme semaine: (du 10/03/2014 au 15/03/2014) ===

(Rien en annexe.)

=== 7éme semaine: (du 17/03/2014 au 22/03/2014) ===

(Rien en annexe.)

=== 8éme semaine: (du 24/03/2014 au 26/03/2014) ===

(Rien en annexe.)

=== 9éme semaine: (du 28/03/2014 au 03/04/2014) ===

[[Fichier:P34_2013_2014_DSC_0061_1_r_2r_semaine_9.jpg|center|thumb|300px|Le réseau R-2R.]]

[[Fichier:P34_2013_2014_DSC_0062_1_4QAM_semaine_9.jpg|center|thumb|300px|4QAM]]

[[Fichier:P34_2013_2014_DSC_0066_1_16QAM_semaine_9.jpg|center|thumb|300px|16QAM]]

[[Fichier:P34_2013_2014_DSC_0069_1_64QAM_semaine_9.jpg|center|thumb|300px|64QAM]]

Pas de photos pour la constellation à 256 points, mais elle a été réalisés.

Pour ce qui est du montage, malgré que la P.L.L., on a un signal d'erreur après filtrage :

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Chaine 1: Vtune (commande du V.C.O.)/Chaine 2: "erreur" de commande]]

Ce qui mets en valeur immédiatement deux problèmes majeur:

La chaine fonctionne sur le papier, mais lors de sa mise en pratique, il faut penser à mettre une tension d'offset et aussi réaliser une amplification de l'erreur pour avoir des grandeur de commande adapté au Vtune du V.C.O..

On propose l'amélioration suivante (qui sera réalisé à la prochaine séance):

[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Proposition de voie d'amélioration.]]

On remarquera que les valeurs des résistances et des capacité on était choisit pour permettre un fonctionnement correct des A.O. (Amplificateur Opérationnel), mais pas pour ce qui de l'asservissement de la boucle par manque de temps.

A la fin de cette, on a eu à démonter le montage à cause de contraintes concernant les mini-circuits (car utilisé en travaux pratiques).

=== 10éme semaine: (rédaction en cours) (du 07/04/2014 au 10/04/2014) ===

== Annexe B: Digilent Spartan 3 ==

=== Procédure pour faire fonctionner la carte Digilent Spartan 3: ===

Ne connectez pas de connecteur JTAG pendant les installations. Redémarrez après chaque installation.

Tout d'abord, il faut savoir que le l'ISE Webpack 14.6 fonctionne avec la carte (n'utilisez pas la 14.7, elle ne supporte pas la génération spartan 3 !):

Installez donc l'ISE WebPack 14.6 (ou antérieur à condition que celle-ci soit supérieur à la 7.1i (d'aprés leur documentation))

(voir lien utile sur Xilinx)

Une fois l'installation de l'ISE terminé, faites en sorte d'avoir celui que soit opérationnel (la licence est gratuite !).

Installez la "library" ADEPT 2.3 voir le lien utile.

Après vous n'avez plus qu'a utilisez ISE Xilinx normalement et vous serez capable de reconnaitre la carte via la liaison JTAG, et de le programmer.

=== Liens utiles: ===

Lien constructeur/vendeur (avec ressources utiles en bas de la page):

http://www.digilentinc.com/Products/Detail.cfm?Prod=S3BOARD

Lien "Library" pour le câble USB digilent:

http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,66,69&Prod=ADEPT

Lien Xilinx (Pour l'ISE 14.6):

http://www.xilinx.com/products/design-tools/ise-design-suite/index.htm

Lien Xilinx (Pour les versions antérieures veuillez faire attention au système d'exploitation, votre architecture matérielle et le FPGA cible):

(Les informations de compatibilité son sur la page suivante:) (mots clés: xilinx classic(s))

http://www.xilinx.com/tools/classics.htm

=== Procédure pour faire une programmation en volatile: ===

Générer le bitstream, et le charger.

=== Procédure pour faire une programmation en "non"-volatile: ===

Générer le bitstream et l'utiliser pour générer un .mcs qui vous permettra d'inscrire le programme dans la mémoire (E?)PROM.

On remarquera que la programmation en non-volatile est utile pour faire un remise à zéro et recharger le contenu de l'(E?)PROM, mais semble être sensible au débranchement de l'adaptateur d'alimentation de la carte.

=== Exemple de programmation: ===

Voir le lien digilent pour ceci dans cette annexe.