Ich habe gerade angegeben, Vivado in einem neuen Projekt zu verwenden und möchte die Projektdateien unter SVN stellen.

Vivado scheint alle Projektdateien unter dem Projektnamen zu erstellen (sagen wir proj1):

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

Meine Frage ist, was sind die Dateien, die ich unter SVN anders als die XDC- und die XPR-Datei setzen muss?

Xilinx erstellt ein YouTube-Video (seufz), um damit umzugehen. Hier ist der Link zum Video

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

Hier ist meine Zusammenfassung des Videos (8 Minuten)

Bevor du anfängst

Wenn Sie die vollständige Kontrolle wirklich mögen, empfiehlt Xilinx, dass Sie auf die GUI vollständig verzichten und alles in der Befehlszeile tun, und dann wissen Sie, was die Quelle ist und was nicht.

Andernfalls erkennt Xilinx, dass Vivado-Projekte nicht für die Versionskontrolle ausgelegt sind. ÜBERPRÜFEN SIE DAS GESAMTE PROJEKT NICHT. Aber lesen Sie weiter für Hinweise ...

Grundlinie

Natürlich sollte alles, was Sie außerhalb des Vivado-Tools schreiben, eingecheckt werden.

Checken Sie die folgenden Dateien ein

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

IP-Blöcke

Wenn Sie IP-Blöcke verwenden, generieren Sie die IP in einem eindeutigen Ordner und checken Sie alles ein.

Checkpoints

Wenn Sie in der Lage sein möchten, Teile des Ablaufs erneut auszuführen, ohne alles auszuführen, checken Sie die Checkpoint-Dateien ein.

*.dcp - Design Checkpoints

Mein Nachtrag

Wenn die Xilinx-Tools effizient wären, würde ich nicht empfehlen, die DCP-Dateien einzuchecken, aber die Ausführung dauert so viele Stunden, dass es sich auf Kosten eines hässlichen Versionskontrollsystems lohnen könnte.

Das Video sagt nichts über die Vivado-Projektdateien (* .xpr) aus. Deshalb hier mein Vorschlag:

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

Die von Xilinx empfohlene Alternative (bei der es sich um einen Hack handelt, der für die Versionskontrolle nicht geeignet ist) besteht darin, den File -> Write Project TclBefehl jedes Mal auszuführen, wenn Sie einen Commit durchführen möchten, und diese TCL-Datei anschließend der Versionskontrolle zuzuweisen. Wenn Sie Ihren lokalen Ordner aktualisieren, müssen Sie diese TCL-Datei erneut ausführen, um alle Projektdateien zu erstellen. Yuck.

Vivado 2014.1 ermöglicht die Verwendung von .tcl-Skripten, um Projekte neu zu generieren.

Gehen Sie dazu bei geöffnetem Projekt zu Datei -> Projekt schreiben tcl.

Grundlegende Projekte

Normalerweise speichere ich meine Quellen und mein .tcl-Skript an einem Ort außerhalb des Projektverzeichnisses. Die im Rahmen des Projekts generierten xilinx-IP-Cores können an eine andere Stelle kopiert werden, indem Sie mit der rechten Maustaste auf den Core klicken und "IP kopieren" auswählen. Und das Original löschen. Wenn das tcl-Skript generiert wird, werden relative Links zu diesen Dateien erstellt. So sieht meine Verzeichnisstruktur normalerweise aus:

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

Es müssen nur die IP-XML- und -XCI-Dateien festgeschrieben werden. (Und selbst das ist technisch nicht notwendig, siehe Anmerkungen am Ende).

Dies ist, was zu Git verpflichtet wird, beachten Sie das Fehlen von project.xpr oder Projektverzeichnissen.

Beim Ausführen genproject.tclwird ein anderes Verzeichnis für das Projekt erstellt.

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

Dieser neue Ordner ist vollständig wegwerfbar. Um diese Struktur zu erstellen, ändere ich das tcl-Skript folgendermaßen.

Ich ändere die ersten 3 Zeilen wie folgt:

# 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

Dadurch wird ein neues Projektverzeichnis und das neue Projekt in diesem Verzeichnis erstellt.

Dann ändere ich die Pfade, um auf die richtigen Stellen zu zeigen. Möglicherweise müssen Sie diese Pfade an anderen Stellen im Skript ändern.

# 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

Ich ändere auch die Entwurfsabläufe für IP-Kerne, wie in dieser Antwort zu sehen .

Die .wcfg-Dateien können auf ähnliche Weise wie die Dateien ip und srcs eingefügt werden.

Hier endet die Verarbeitung für einfachere Projekte (die nur Quellen und IP enthalten, keine Blockdiagramme). Das Folgende muss ebenfalls durchgeführt werden, um die Blockdiagrammdaten zu speichern.

Blockdiagramm-Projekte

Um das Blockdiagramm zu speichern, gehen Sie bei geöffnetem Blockdiagramm zu Datei -> Exportieren -> Blockdiagramm in Tcl und speichern Sie es im selben Verzeichnis wie die andere Tcl-Datei.

Dann habe ich ein Generate_Wrapper.tclSkript erstellt, das die Wrapper-Dateien für Blockdiagramme erstellt, sodass Sie dies nicht manuell tun müssen. Der Ordner project / project.srcs wird zum Speichern der BD-Daten verwendet, ist jedoch immer noch vollständig verfügbar, da die BD im tcl-Skript gespeichert ist. Speichern Sie dies mit den anderen beiden.

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

Am Ende von my genproject.tclfüge ich die folgenden Zeilen hinzu, um das Blockdiagramm und die Wrapper zu generieren:

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

Für Projekte ohne Quelle (nur Blockdiagramm) lautet mein git-Commit wie folgt:

base_project/
 Generate_Wrapper.tcl
 Create_Bd.tcl
 genproject.tcl

Führen Sie aus, um alles zu generieren genproject.tcl .

Sie können all dies sogar zu einem kombinieren, wenn Sie besonders effizient sind. Darauf bin ich noch nicht gekommen.

Benutzerdefinierte Komponenten: Das Komponentenprojekt

Noch ein kurzer Hinweis zum Erstellen einer benutzerdefinierten Komponente. Wenn Sie eine component.xml haben, fügen Sie diese Ihrer tcl-Quellenliste hinzu:

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

Fügen Sie dann auch den folgenden Abschnitt hinzu:

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

Dies schließt das Komponentendesign für eine einfache Anpassung in das Projekt ein.

Benutzerdefinierte Komponenten: Verweisen auf Ihre Komponente

Sie können Ihren benutzerdefinierten Komponenten-Repo-Pfad folgendermaßen einteilen:

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

In meinem Repo-Ordner befinden sich einzelne Ordner mit XML-Dateien. Sie verweisen also nicht auf den Ordner mit der XML-Datei, sondern auf den übergeordneten Ordner. Z.B:

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

Wie führen wir diese Tcl-Skripte aus?

Öffnen Sie Vivado und ohne Projekte zu öffnen, wählen Sie Extras -> TCL-Skript ausführen und navigieren Sie zu Ihrem Skript.

Zusätzliche TCL-Notizen

Jeder Befehl, den Sie in Vivado ausführen, wird in der tcl-Konsole als tcl-Befehl angezeigt. Wenn ich zum Beispiel eine neue Xilinx-IP über die GUI generiert habe, wurde dies in der tcl-Konsole angezeigt:

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]

Das bedeutet ein paar Dinge:

• Sie müssen nicht einmal wirklich xilinx-IP-Kerne speichern. Kopieren Sie die Befehle in das tcl-Skript, sobald sie Ihren Wünschen entsprechen, und Sie müssen ip / nicht mehr festschreiben.

• Geben Sie das IP-Verzeichnis mit dem Argument -dir nach -module_name an, um es an der gewünschten Stelle abzulegen (standardmäßig in project.srcs).

• Fast alles, was Sie in der GUI tun, können Sie in tcl tun. Der einfachste Weg, um zu sehen, wie Xilinx etwas tut, ist, es in der GUI zu tun und sich anschließend anzusehen, was sich in der TCL-Konsole befindet.

• In diesem umfangreichen PDF werden alle vivado tcl-Befehle detailliert beschrieben.

Es gibt ein Xilinx-Schulungsvideo, in dem erklärt wird, wie Versionskontrollsysteme mit Vivado verwendet werden. Grundsätzlich hängt die Liste der Dateien von den von Ihnen verwendeten Funktionen ab.

Wenn Sie einen skriptbasierten Ansatz verwenden (wie dies bei vermaete der Fall ist), können Sie Vivado veranlassen, alle Zwischen- / temporären Dateien in ein separates Verzeichnis zu schreiben ( siehe hier ), damit Sie sie problemlos trennen können.

Andernfalls können Sie den Build-Ordner von Vivado bereinigen und alles, was übrig bleibt, wird möglicherweise unter Versionskontrolle gestellt.

Bitte schauen Sie sich diesen Thread in den Xilinx-Foren an:

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