Ho appena dichiarato di utilizzare Vivado in un nuovo progetto e vorrei mettere i file del progetto in SVN.

Vivado sembra creare tutti i file di progetto con il nome del progetto (ad esempio proj1):

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

La mia domanda è: quali sono i file che devo inserire in SVN diversi dal file XDC e XPR?

Xilinx crea un video di YouTube (sospiro) per far fronte a questo. Ecco il link al video

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

Ecco il mio riassunto del video (8 minuti)

Prima che inizi

Se ti piace davvero il pieno controllo, Xilinx ti suggerisce di rinunciare completamente alla GUI e di fare tutto sulla riga di comando, quindi sai cos'è la fonte e cosa no.

Altrimenti, Xilinx si rende conto che i progetti Vivado non sono progettati per il controllo della versione. NON CONTROLLARE IN TUTTO IL PROGETTO. Ma continua a leggere per suggerimenti ...

Baseline

Ovviamente, tutto ciò che scrivi al di fuori dello strumento Vivado deve essere archiviato.

Controlla i seguenti file

*.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

Blocchi IP

Se si utilizzano blocchi IP, generare l'IP in una cartella univoca e archiviare tutto.

Punti di controllo

Se si desidera poter rieseguire parti del flusso senza eseguire tutto, controllare nei file del checkpoint.

*.dcp - Design Checkpoints

Il mio addendum

Se gli strumenti di Xilinx fossero efficienti, non consiglierei di controllare i file dcp, ma impiegano così tante ore per funzionare, potrebbe valere la pena a scapito di un brutto sistema di controllo della versione.

Il video non dice uno squat sui file di progetto Vivado (* .xpr), quindi ecco il mio suggerimento:

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

L'alternativa raccomandata da Xilinx (che è davvero un trucco, non adatto al controllo della versione) è eseguire il File -> Write Project Tclcomando ogni volta che si desidera eseguire il commit, quindi eseguire il commit del file TCL sul controllo della versione. Quando si aggiorna la cartella locale, è necessario rieseguire quel file TCL per creare tutti i file di progetto. Che schifo.

Vivado 2014.1 consente l'utilizzo di script .tcl per rigenerare i progetti.

Per fare questo, con il progetto aperto, vai su File -> Scrivi progetto tcl.

Progetti di base

Di solito conservo le mie fonti e lo script .tcl in una posizione esterna alla directory del progetto. I core IP xilinx generati all'interno del progetto possono essere copiati altrove facendo clic con il tasto destro del mouse sul core e selezionando "Copia IP". E cancellando l'originale. Quando viene generato lo script tcl, crea collegamenti relativi a questi file. Di solito è come appare la mia struttura di directory:

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

È necessario eseguire il commit solo dei file IP .xml e .xci. (E anche questo non è necessario, tecnicamente, vedi note alla fine).

Questo è ciò che si impegna a git, nota la mancanza di project.xpr o delle directory di progetto.

Quando corro genproject.tcl, crea un'altra directory per il progetto.

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

Questa nuova cartella è completamente usa e getta. Per creare questa struttura, modifico lo script tcl nel modo seguente.

Cambio le prime 3 righe come segue:

# 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

Questo crea una nuova directory di progetto e il nuovo progetto in quella directory.

Quindi modifico i percorsi per puntare ai posti corretti. Potrebbe essere necessario modificare questi percorsi in altri punti dello 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

Modifico anche le esecuzioni di progettazione per i core IP come visto in questa risposta .

I file .wcfg possono essere inclusi in modo simile a ip e srcs.

Qui è dove l'elaborazione termina per progetti più semplici (contenenti solo sorgenti e IP, nessun diagramma a blocchi). È inoltre necessario eseguire le seguenti operazioni per memorizzare i dati dello schema a blocchi.

Progetti di diagrammi a blocchi

Per salvare lo schema a blocchi, con lo schema a blocchi aperto, vai su File -> Esporta -> Schema a blocchi su Tcl e salvalo nella stessa directory dell'altro file tcl.

Quindi ho creato uno Generate_Wrapper.tclscript che crea i file wrapper dello schema a blocchi, quindi non è necessario farlo manualmente. La cartella project / project.srcs viene utilizzata per archiviare i dati bd, ma è ancora completamente usa e getta, poiché bd è archiviato nello script tcl. Salva questo con gli altri due.

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

Alla fine genproject.tclaggiungo le seguenti righe per generare lo schema a blocchi e i wrapper:

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

Per i progetti senza sorgente (solo diagramma a blocchi), il mio git commit è solo il seguente:

base_project/
 Generate_Wrapper.tcl
 Create_Bd.tcl
 genproject.tcl

Per generare tutto, esegui genproject.tcl.

Puoi anche combinare tutti questi elementi in uno solo se sei particolarmente efficiente, non ci sono ancora riuscito.

Componenti personalizzati: il progetto del componente

Un'altra breve nota sulla creazione di un componente personalizzato. Se hai un component.xml, aggiungilo al tuo elenco di fonti tcl:

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

E poi aggiungi anche la seguente sezione:

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

Ciò include la progettazione dei componenti nel progetto per una facile personalizzazione.

Componenti personalizzati: riferimento al componente

È possibile spaziare il percorso repository del componente personalizzato in questo modo:

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

Nella mia cartella repo, ci sono singole cartelle contenenti file .xml. Quindi non stai facendo riferimento alla cartella contenente il file .xml, ma il genitore di quello. Per esempio:

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

Come eseguiamo questi script tcl?

Apri Vivado e, senza aprire alcun progetto, seleziona Strumenti -> Esegui script TCL e vai al tuo script.

Note TCL extra

Ogni comando eseguito in Vivado viene mostrato nella console tcl come comando tcl. Ad esempio, quando ho generato un nuovo IP Xilinx utilizzando la GUI, questo si è verificato nella 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]

Questo significa un paio di cose:

• Non hai nemmeno bisogno di salvare i core IP di xilinx: una volta che sono come li desideri, copia i comandi nello script tcl e non devi più eseguire il commit di ip /.

• specifica la directory IP con l'argomento -dir dopo -module_name per posizionarla dove preferisci (per impostazione predefinita è in project.srcs).

• Quasi tutto ciò che fai nella GUI può essere fatto in tcl, il modo più semplice per vedere come xilinx fa le cose è farlo nella GUI e poi guardare cosa c'è nella console TCL in seguito.

• Questo enorme pdf dettaglia tutti i comandi vivado tcl.

C'è un video di formazione Xilinx che spiega come utilizzare i sistemi di controllo versione con Vivado. Fondamentalmente, l'elenco dei file dipende dalle funzionalità che stai utilizzando.

Se usi un approccio con script (come fa vermaete), puoi far scrivere a Vivado tutti i file intermedi / temporanei in una directory separata ( vedi qui ), in modo da poterli separare facilmente.

Altrimenti, puoi ripulire la cartella di build da Vivado e tutto ciò che rimane potrebbe essere messo sotto il controllo della versione.

Dai un'occhiata a questa discussione sui forum di Xilinx:

http://forums.xilinx.com/t5/Implementation/What-files-to-put-under-revision-control-for-consistent-build/td-p/174232