Vous utilisez SVN avec Xilinx Vivado?

13

Je viens de dire que j'utilise Vivado dans un nouveau projet et je voudrais mettre les fichiers du projet sous SVN.

Vivado semble créer tous les fichiers du projet sous le nom du projet (disons proj1):

/<path to the project>/proj1/
                            proj1.xpr
                            proj1.srcs/
                                       constrs_1/
                                                new/
                                                    const1.xdc
                            proj1.runs/
                            proj1.data/
                            proj1.cache/

Ma question est quels sont les fichiers que je dois mettre sous SVN autres que le XDC et le fichier XPR?

fpga xilinx FarhadA
la source
1
Pourquoi pensez-vous que vous n'avez pas besoin de tout si eux?
Grady Player
6
Je ne comprends pas ce que tu veux dire ici. Vivado crée une merde de fichiers qui n'ont pas besoin d'être contrôlés car ils sont générés. Mes fichiers source sont ailleurs, j'ai juste besoin d'enregistrer les fichiers importants pour Vivado.
FarhadA
Je dirais que puisque la seule entrée est le code source, c'est le seul fichier à mettre sous SVN. Mais je ne l'ai jamais utilisé, je devine
clabacchio
Y a-t-il une option propre? Vous pouvez nettoyer puis tout vérifier.
Grady Player
2
Je crée un script TCL pour régénérer le projet Vivado. Et mettez celui-ci sous contrôle de version. Lors de la construction du projet (avec make), il créera les fichiers dont Xilinx a besoin. Cela m'empêche d'avoir à archiver le répertoire complet du projet et les fichiers de Xilinx.
vermaete

Réponses:

6

Xilinx crée une vidéo YouTube (soupir) pour y faire face. Voici le lien de la vidéo

http://www.xilinx.com/training/vivado/vivado-version-control-overview.htm

Voici mon résumé de la vidéo (8 minutes)

Avant de commencer

Si vous aimez vraiment le contrôle total, Xilinx vous suggère de renoncer entièrement à l'interface graphique et de tout faire sur la ligne de commande, puis vous savez ce qui est source et ce qui ne l'est pas.

Sinon, Xilinx se rend compte que les projets Vivado ne sont pas conçus pour le contrôle de version. NE VÉRIFIEZ PAS L'INTÉGRALITÉ DU PROJET. Mais lisez la suite pour des conseils ...

Référence

Bien sûr, tout ce que vous écrivez en dehors de l'outil Vivado doit être archivé.

Archivez les fichiers suivants

*.v, *.vh, *.vhdl, *.edif  - HDL and Netlist
*.xdc - Constraints
*.xci - IP Core
*.bd  - IP Integrator Block Diagram
*.xmp - Embedded Subsystem
*.sgp - System Generator Subsystem
*.bmm
*.cdc - Chipscope
*.elf
*.mem

Blocs IP

Si vous utilisez des blocs IP, générez l'adresse IP dans un dossier unique et archivez tout.

Points de contrôle

Si vous souhaitez pouvoir réexécuter des parties du flux sans tout exécuter, archivez les fichiers de point de contrôle.

*.dcp - Design Checkpoints

Mon addendum

Si les outils Xilinx étaient efficaces, je ne recommanderais pas d'archiver les fichiers dcp, mais ils prennent tellement d'heures à fonctionner, cela pourrait valoir la peine au prix d'un système de contrôle de version laid.

La vidéo ne dit pas squat sur les fichiers du projet Vivado (* .xpr) alors voici ma suggestion:

*.xpr
*.data/*/fileset.xml
*.data/*/runs.xml

L'alternative que Xilinx recommande (qui est vraiment un hack, ne convient pas au contrôle de version) est d'exécuter la File -> Write Project Tclcommande chaque fois que vous souhaitez valider, puis de valider ce fichier TCL en contrôle de version. Lorsque vous mettez à jour votre dossier local, vous devez réexécuter ce fichier TCL pour créer tous les fichiers de projet. Beurk.

Mark Lakata
la source
Super, c'était vraiment utile. Je n'utilise plus SVN, mais GIT, mais cela m'aide à obtenir les bons fichiers dans le référentiel.
FarhadA
1
J'utilise les fichiers tcl et cela fonctionne vraiment très bien. Les scripts tcl n'ont besoin d'être mis à jour que lorsqu'un fichier est ajouté à un projet, et généralement je génère la tcl lorsque tous les fichiers sont entrés.
stanri
La solution TCL serait idéale si Vivado créait automatiquement le fichier TCL après chaque changement de projet ET lisait le fichier TCL en tant que fichier "projet" au lieu du fichier xpr. En d'autres termes, si Xilinx s'est débarrassé du fichier xpr et l'a remplacé par le fichier tcl.
Mark Lakata
Il y a un léger problème avec la validation du fichier xpr: il change à chaque fois, même lorsque vous n'ouvrez que Vivado ...
Piedone
3

Vivado 2014.1 permet l'utilisation de scripts .tcl pour régénérer des projets.

Pour ce faire, avec votre projet ouvert, allez Fichier -> Écrire le projet tcl.

Projets de base

Je stocke généralement mes sources et mon script .tcl dans un emplacement en dehors du répertoire du projet. Les cœurs IP xilinx générés dans le projet peuvent être copiés ailleurs en cliquant avec le bouton droit sur le cœur et en sélectionnant "Copier IP". Et en supprimant l'original. Lorsque le script tcl est généré, il crée des liens relatifs vers ces fichiers. Voici généralement à quoi ressemble la structure de mon répertoire:

base_project/
 srcs/
  project.v
 ip/
  ip1/
   ip1.xml
   ip1.xci
 genproject.tcl

Seuls les fichiers IP .xml et .xci doivent être validés. (Et même cela n'est pas nécessaire, techniquement, voir les notes à la fin).

C'est ce qui s'engage à git, notez le manque de project.xpr ou de répertoires de projet.

Lorsque je cours genproject.tcl, il crée un autre répertoire pour le projet.

base_project/
 srcs/
 ip/
 genproject.tcl
 projectdir/
  project.runs/
  project.cache/
  project.xpr

Ce nouveau dossier est entièrement jetable. Afin de créer cette structure, je modifie le script tcl de la manière suivante.

Je change les 3 premières lignes comme suit:

# Set the reference directory for source file relative paths (by default the value is script directory path)
set origin_dir [file dirname [info script]]

# Set the directory path for the original project from where this script was exported
set orig_proj_dir "[file normalize "$origin_dir/projectdir"]"

# Create project
create_project project $projectdir/project

Cela crée un nouveau répertoire de projet et le nouveau projet dans ce répertoire.

Ensuite, je modifie les chemins pour pointer vers les bons endroits. Vous devrez peut-être modifier ces chemins à d'autres endroits du script.

# Set 'sources_1' fileset object
set obj [get_filesets sources_1]
set files [list \
 "[file normalize "$origin_dir/srcs/project.v"]"\
 "[file normalize "$origin_dir/ip/ip1/ip1.xci"]"\
]
add_files -norecurse -fileset $obj $files

Je modifie également les cycles de conception pour les cœurs IP comme indiqué dans cette réponse .

Les fichiers .wcfg peuvent être inclus d'une manière similaire à l'ip et au srcs.

C'est là que le traitement se termine pour des projets plus simples (contenant uniquement des sources et IP, pas de diagrammes). Les opérations suivantes doivent également être effectuées afin de stocker les données du diagramme.

Projets de diagramme

Pour enregistrer le diagramme, avec le diagramme ouvert, allez Fichier -> Exporter -> Diagramme de blocs vers Tcl, et enregistrez-le dans le même répertoire que l'autre fichier tcl.

Ensuite, j'ai créé un Generate_Wrapper.tclscript qui crée les fichiers d'encapsulation du diagramme pour que vous n'ayez pas besoin de le faire manuellement. Le dossier project / project.srcs est utilisé pour stocker les données bd, mais il est toujours complètement jetable, car le bd est stocké dans le script tcl. Enregistrez cela avec les deux autres.

set origin_dir [file dirname [info script]]

make_wrapper -files [get_files $origin_dir/project/project.srcs/sources_1/bd/design_1/design_1.bd] -top
add_files -norecurse -force $origin_dir/project/project.srcs/sources_1/bd/design_1/hdl/design_1_wrapper.v
update_compile_order -fileset sources_1
update_compile_order -fileset sim_1

À la fin de mon, genproject.tclj'ajoute les lignes suivantes pour générer le diagramme et les wrappers:

source $origin_dir/Create_bd.tcl
source $origin_dir/Generate_Wrapper.tcl
regenerate_bd_layout

Pour les projets sans source (juste un diagramme), mon git commit est juste le suivant:

base_project/
 Generate_Wrapper.tcl
 Create_Bd.tcl
 genproject.tcl

Pour tout générer, lancez genproject.tcl.

Vous pouvez même combiner tous ces éléments en un seul si vous êtes particulièrement efficace, je n'y suis pas encore arrivé.

Composants personnalisés: le projet de composants

Une autre note rapide sur la création d'un composant personnalisé. Si vous avez un component.xml, ajoutez-le à votre liste de sources tcl:

  "[file normalize "$origin_dir/component.xml"]"\

Et puis ajoutez également la section suivante:

set file "$origin_dir/component.xml"
set file [file normalize $file]
set file_obj [get_files -of_objects [get_filesets sources_1] [list "*$file"]]
set_property "file_type" "IP-XACT" $file_obj

Cela inclut la conception des composants dans le projet pour une personnalisation facile.

Composants personnalisés: référencer votre composant

Vous pouvez espacer votre chemin de dépôt de composants personnalisé comme ceci:

# Set IP repository paths
set obj [get_filesets sources_1]
set_property "ip_repo_paths" "[file normalize "$origin_dir/path/to/repository"]" $obj

Dans mon dossier repo, il y a des dossiers individuels contenant des fichiers .xml. Vous ne faites donc pas référence au dossier contenant le .xml, mais au parent de celui-ci. Par exemple:

repository/
 component1/component1.xml
 component2/component2.xml

Comment exécuter ces scripts tcl?

Ouvrez Vivado et sans ouvrir aucun projet, sélectionnez Outils -> Exécuter le script TCL et accédez à votre script.

Notes TCL supplémentaires

Chaque commande que vous exécutez dans Vivado est affichée dans la console tcl en tant que commande tcl. Par exemple, lorsque j'ai généré une nouvelle adresse IP Xilinx à l'aide de l'interface graphique, cela est apparu dans la console tcl:

create_ip -name floating_point -vendor xilinx.com -library ip -module_name floating_point_0
set_property -dict [list CONFIG.Operation_Type {Fixed_to_float} CONFIG.A_Precision_Type {Custom} CONFIG.C_A_Exponent_Width {38} CONFIG.C_A_Fraction_Width {0} CONFIG.Result_Precision_Type {Custom} CONFIG.C_Result_Exponent_Width {8} CONFIG.C_Result_Fraction_Width {16} CONFIG.Flow_Control {NonBlocking} CONFIG.Has_ARESETn {true}] [get_ips floating_point_0]

Cela signifie plusieurs choses:

  • Vous n'avez même pas vraiment besoin d'enregistrer les cœurs ip xilinx - une fois qu'ils sont comme vous le souhaitez, copiez les commandes dans le script tcl et vous n'avez plus besoin de valider ip /.

  • spécifiez le répertoire IP avec l'argument -dir après -module_name pour le placer où vous le souhaitez (par défaut, il est dans project.srcs).

  • La plupart du temps, tout ce que vous faites dans l'interface graphique peut être fait en tcl, le moyen le plus simple de voir comment xilinx fait les choses est de le faire dans l'interface graphique et de regarder ensuite ce qui se trouve dans la console TCL.

  • Ce pdf gigantesque détaille toutes les commandes vivado tcl.

Stanri
la source
2

Il existe une vidéo de formation Xilinx qui explique comment utiliser les systèmes de contrôle de version avec Vivado. Fondamentalement, la liste des fichiers dépend des fonctionnalités que vous utilisez.

Si vous utilisez une approche scriptée (comme le fait vermaete), vous pouvez demander à Vivado d'écrire tous les fichiers intermédiaires / temporaires dans un répertoire séparé ( voir ici ), afin que vous puissiez facilement les séparer.

Sinon, vous pouvez nettoyer le dossier de construction par Vivado, et tout ce qui reste peut être placé sous contrôle de version.

hli
la source
1
Merci, je vais y jeter un œil, il est juste étonnant que Xilinx puisse proposer un outil si cher mais ne prend même pas la peine de fournir un support approprié pour le contrôle des révisions avec lui.
FarhadA
1
Il y a eu un commentaire intéressant sur les forums Xilinx (à partir de 2009 IIRC): les outils étaient destinés aux ingénieurs hardware. Et les ingénieurs du matériel ne connaissent pas et ne se soucient pas du contrôle des révisions. Mais je suppose que cette attitude a changé, et de plus en plus d'ingénieurs SW utilisent ces outils. Le contrôle des révisions est donc plus important que par le passé.
hli
2
Eh bien, c'est une pure insulte qui a jamais dit ces mots. Les ingénieurs HW utilisent différents types de contrôle de révision, de nombreux outils prennent en charge cela, de nombreux ingénieurs le font à l'aide de RC standard, et d'autres utilisent des outils comme Mentor HDL designer avec RC intégré. Malheureusement, les fournisseurs de FPGA comme Xilinx et Altera ne semblent pas se soucier de ces problèmes, et c'est là que réside le principal problème.
FarhadA