FPGA CPLD : Mon projet sur le SVN

De Wiki_du_Réseau_des_Electroniciens_du_CNRS
Aller à la navigationAller à la recherche

Vous voulez partager un projet avec le réseau des électroniciens ou écrire une bibliothèque de composants en VHDL, pas de problème! Le SVN est là pour ça.

Pour utiliser le SVN, suivez les instructions à la page suivante selon la plateforme que vous utilisez.

Organisation des répertoires

Si vous souhaitez utiliser le SVN, vous devez dans un premier temps vous référer aux différents "_Read_Me.txt" se trouvant dans les répertoires.

  • ReadMe du répertoire principal expliquant l'organisation des répertoires, donnant le nom des contributeurs et les recommandations pour l'ajout des fichiers sources. NB : Vous retrouverez sur cette page la plupart des informations de ce document.
  • ReadMe du répertoire projet donnant les recommandations pour l'organisation d'un répertoire projet.
  • ReadMe modèle pour la description d'un projet.


    Groupe_FPGA_CPLD
       |                              _
       +--- _Demos                   |
       +--- _Librairies              |_ Répertoires communs aux différentes architectures
       +--- _Ressources             _|
       |                              _
       +--- Hardware                 |
       +--- Tutoriel                 |- Dossiers de partage 
       +--- Projets                 _|
               |                      _
               +--- _Template       _|- Dossier d'exemple pour l'organisation d'un nouveau projet
               |                      _
               +--- Work_In_Progress_|- Dossier des projets en cours
               |                      _
               +--- Release	      _|- Dossier des versions de projets abouties

Le dossier _Demos contient des fichiers de programmation pour les cartes de développement fournis par les fabricants et des demo 'clé en main' faites par les utilisateurs.

Le dossier _Librairies contient des librairies développées par les utilisateurs pour des utilisations communes à différentes architectures.

Le dossier _Ressources contient des fichiers que vous pouvez réutiliser pour vos développements comme des fichiers de contraintes pour les cartes de développement. Il contient aussi des templates pour vos designs.

Le dossier Hardware contient des documentations ou des liens vers les documentations des composants utilisées pour les designs et projets.

Le dossier Tutoriel contient des fichiers et projets utilisés pour les tutoriels, en particulier ceux présents sur le wiki du RdE.

Le dossier Projets regroupe l'ensemble des projets qui sont, soit en cours de développement dans le répertoire Work_In_Progress; ou les versions stables de projets aboutis dans le dossier Release. Le dossier _Template est un répertoire d'exemple à copier pour avoir la même organisation lors de la création d'un nouveau projet.

Gestion des sources

Lorsque vous ajoutez un projet sur le SVN avec la commande Add, il n'est pas nécessaire d'ajouter l'ensemble des fichiers contenus dans le répertoire de travail. Xilinx ISE génère une multitude de fichiers qui peuvent être regénérés par n'importe quel utilisateur utilisant Xilinx. A plus forte raison, si une personne utilise un autre outil que Xilinx, il n'a pas besoin des fichiers générés par la compilation. Voici la liste des extensions que vous devez ajouter :

  • Fichiers VHD/VHDL : les fichiers sources contenant votre code en VHDL
  • Fichiers XCO (optionnel) : fichiers sources pour les IP, seul ce fichier suffit à regénérer une IP avec sa configuration
  • Fichiers UCF : le ou les fichiers de contraintes selon les plateformes pour lesquelles votre projet a été développé
  • Fichier XISE (optionnel) : fichier XML utilisé par Xilinx ISE pour reconstituer l'arborescence de votre projet (évite de recréer un nouveau projet et d'y ajouter les fichiers sources)
  • Fichiers WCFG (optionnels) : fichiers contenant les signaux à visualiser et leur configuration pour ISIM (permet de gagner du temps pour relancer les simulations)
  • Fichiers TCL/DO (optionnels) : si vous êtes un habitué ou que vous utilisez ModelSim pour vos simulations

Vous devez aussi ajouter certains fichiers si vous utilisez des RAM/ROM comme les fichiers COE et MIF contenant les données initialisant ces dernières.

Conventions de programmation

Pour que tout le monde puisse s'y retrouver lors de la réutilisation de votre projet, il convient de suivre quelques règles de bonnes pratiques.

  • Les fichiers :
    • Le nom du fichier = le nom de l'entité
    • Ce qui sous-entend : Un fichier = une entité (sauf cas exceptionnel)
    • Une entité = une ou plusieurs architectures (ça c'est normal !)
    • Nommez le fichier "Top" avec le nom de votre projet et en lui ajoutant "..._Top" à la fin afin de l'identifier rapidement.
    • Donnez des noms pertinents, et si possible courts, à vos composants. Par exemple "I2C_Slave" pour un module de communication esclave I2C, et non "Module_Com".
    • Si vous avez un fichier de simulation pour un composant, nommez-le avec le même nom en lui ajoutant "..._sim" ou "..._TB" à la fin. De même, si vous utilisez un fichier TCL/DO ou WCFG, donnez lui le même nom que la simulation pour faire le rapprochement facilement. Par exemple, nommez le fichier de simulation "I2C_Slave_sim.vhdl" le fichier de simulation et "I2C_Slave_sim.wcfg" le fichier pour la visualisation de la simulation.
  • Le code :
    • Pensez à la façon dont vous pourrez réutiliser votre composant pour d'autres projets. Écrivez-le le plus générique possible et qu'il ne dépende pas de la plateforme utilisée.
    • De la même façon, utilisez des Generic pour faciliter leur réutilisation.
    • Utilisez le moins possible des variables dans les process. Il existe toujours une façon de s'en passer (fonctions, procédures, signaux). Les raisons : vous ne pouvez pas suivre leur évolution durant une simulation, ce qui rend difficile le debuggage; vous ne faîtes pas d'économies de places et vous pouvez rendre très lent un process sans vous en apercevoir (comme essayer de compter jusqu'à un million pendant une période d'horloge).
    • Utilisez des noms en majuscules pour les constantes et les generic.
    • N'hésitez pas à mettre beaucoup de commentaires dans votre code, en particulier dans l'en-tête.
    • Précisez bien dans les commentaires en en-tête du fichier les dépendances.

Vous pouvez retrouver certaines bonnes pratiques dans les documents suivants :

Et je vous recommande chaudement de lire le document suivant où vous retouverez la plupart des consignes que je viens de citer :

References

<references/>