Właśnie powiedziałem, że korzystam z Vivado w nowym projekcie i chciałbym umieścić pliki projektu pod SVN.

Vivado wydaje się tworzyć wszystkie pliki projektu pod nazwą projektu (powiedzmy proj1):

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

Moje pytanie brzmi: jakie pliki muszę umieścić w SVN poza plikami XDC i XPR?

Xilinx stwórz film na YouTube (westchnienie), aby sobie z tym poradzić. Oto link do filmu

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

Oto moje streszczenie wideo (8 minut)

Zanim zaczniesz

Jeśli naprawdę podoba ci się pełna kontrola, Xilinx sugeruje, aby całkowicie zrezygnować z GUI i zrobić wszystko w wierszu poleceń, a następnie wiesz, co jest źródłem, a co nie.

W przeciwnym razie Xilinx zdaje sobie sprawę, że projekty Vivado nie są przeznaczone do kontroli wersji. NIE SPRAWDZAJ CAŁEGO PROJEKTU. Ale czytaj dalej ...

Linia bazowa

Oczywiście wszystko, co piszesz poza narzędziem Vivado, powinno zostać zarejestrowane.

Sprawdź następujące pliki

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

Bloki IP

Jeśli korzystasz z bloków adresów IP, wygeneruj adres IP w unikalnym folderze i sprawdź wszystko.

Punkty kontrolne

Jeśli chcesz mieć możliwość ponownego uruchomienia części przepływu bez uruchamiania wszystkiego, sprawdź pliki punktów kontrolnych.

*.dcp - Design Checkpoints

Moje uzupełnienie

Gdyby narzędzia Xilinx były wydajne, nie polecałbym sprawdzania plików dcp, ale ich uruchomienie zajmuje tyle godzin, że może to być opłacalne kosztem brzydkiego systemu kontroli wersji.

Film nie mówi o przysiadach na temat plików projektu Vivado (* .xpr), więc oto moja sugestia:

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

Alternatywą zalecaną przez Xilinx (która jest naprawdę włamaniem, nie nadaje się do kontroli wersji) jest uruchomienie File -> Write Project Tclpolecenia za każdym razem, gdy chcesz zatwierdzić, a następnie zatwierdzenie tego pliku TCL do kontroli wersji. Podczas aktualizacji folderu lokalnego musisz ponownie uruchomić ten plik TCL, aby utworzyć wszystkie pliki projektu. Fuj

Vivado 2014.1 pozwala na używanie skryptów .tcl do regeneracji projektów.

Aby to zrobić, przy otwartym projekcie przejdź do Plik -> Napisz projekt tcl.

Podstawowe projekty

Zwykle przechowuję źródła i skrypt .tcl w lokalizacji poza katalogiem projektu. Rdzenie Xilinx IP wygenerowane w ramach projektu można skopiować gdzie indziej, klikając prawym przyciskiem myszy rdzeń i wybierając „Kopiuj IP”. I usuwanie oryginału. Po wygenerowaniu skrypt tcl tworzy względne łącza do tych plików. Tak zwykle wygląda moja struktura katalogów:

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

Należy zatwierdzić tylko pliki .xml i .xci IP. (I nawet to nie jest technicznie konieczne, patrz uwagi na końcu).

To właśnie zobowiązuje się do git, zauważ brak projektu.xpr lub katalogów projektu.

Kiedy uruchamiam genproject.tcl, tworzy inny katalog dla projektu.

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

Ten nowy folder jest całkowicie jednorazowy. Aby utworzyć tę strukturę, modyfikuję skrypt tcl w następujący sposób.

Zmieniam pierwsze 3 linie w następujący sposób:

# 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

Spowoduje to utworzenie nowego katalogu projektu i nowego projektu w tym katalogu.

Następnie modyfikuję ścieżki, aby wskazywały właściwe miejsca. Być może trzeba będzie zmienić te ścieżki w innych miejscach skryptu.

# 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

Zmieniam również przebiegi projektowania rdzeni IP, jak widać w tej odpowiedzi .

Pliki .wcfg można dołączyć w podobny sposób jak pliki ip i srcs.

W tym miejscu przetwarzanie kończy się w przypadku prostszych projektów (zawierających tylko źródła i adres IP, bez schematów blokowych). Aby zapisać dane schematu blokowego, należy również wykonać następujące czynności.

Projekty schematów blokowych

Aby zapisać schemat blokowy, przy otwartym schemacie blokowym, przejdź do Plik -> Eksportuj -> Schemat blokowy do Tcl i zapisz go w tym samym katalogu, co inny plik tcl.

Potem stworzyłem Generate_Wrapper.tclskrypt, który tworzy pliki otoki diagramu blokowego, więc nie musisz tego robić ręcznie. Folder project / project.srcs służy do przechowywania danych bd, ale nadal jest całkowicie jednorazowy, ponieważ bd jest przechowywany w skrypcie tcl. Zapisz to z pozostałymi dwoma.

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

Na końcu genproject.tcldodaję następujące wiersze, aby wygenerować schemat blokowy i opakowania:

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

W przypadku projektów bez źródła (tylko schemat blokowy) mój git commit jest następujący:

base_project/
 Generate_Wrapper.tcl
 Create_Bd.tcl
 genproject.tcl

Aby wygenerować wszystko, uruchom genproject.tcl.

Możesz nawet połączyć je wszystkie w jedno, jeśli jesteś szczególnie wydajny, jeszcze do tego nie doszedłem.

Komponenty niestandardowe: projekt komponentu

Kolejna szybka uwaga na temat tworzenia niestandardowego komponentu. Jeśli masz plik component.xml, dodaj go do listy źródeł tcl:

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

A następnie dodaj także następującą sekcję:

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

Obejmuje to projekt komponentu w projekcie w celu łatwej personalizacji.

Komponenty niestandardowe: Odwoływanie się do komponentu

Ścieżkę repozytorium niestandardowego elementu można rozmieścić w następujący sposób:

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

W moim folderze repo znajdują się pojedyncze foldery zawierające pliki .xml. Więc nie odwołujesz się do folderu zawierającego .xml, ale nadrzędny dla tego. Na przykład:

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

Jak uruchamiamy te skrypty tcl?

Otwórz Vivado i bez otwierania żadnych projektów wybierz Narzędzia -> Uruchom skrypt TCL i przejdź do swojego skryptu.

Dodatkowe notatki TCL

Każde polecenie uruchomione w Vivado jest pokazane w konsoli tcl jako polecenie tcl. Na przykład, kiedy wygenerowałem nowy adres IP Xilinx za pomocą GUI, pojawiło się to w konsoli 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]

Oznacza to kilka rzeczy:

• Naprawdę nie musisz nawet zapisywać rdzeni ip xilinx - gdy są takie, jakie chcesz, skopiuj polecenia do skryptu tcl i nie musisz już zatwierdzać ip /.

• określ katalog IP za pomocą argumentu -dir po opcji -module_name, aby umieścić go w dowolnym miejscu (domyślnie jest to plik project.srcs).

• Przeważnie wszystko, co robisz w GUI, można zrobić w tcl, najłatwiejszym sposobem, aby zobaczyć, jak robi to xilinx, jest zrobienie tego w GUI, a następnie sprawdzenie, co jest w konsoli TCL.

• Ten obszerny plik PDF szczegółowo opisuje wszystkie polecenia vivado tcl.

Istnieje film szkoleniowy Xilinx, który wyjaśnia, jak używać systemów kontroli wersji z Vivado. Zasadniczo lista plików zależy od używanych funkcji.

Jeśli używasz podejścia skryptowego (jak robi to vermaete), możesz poprosić Vivado o zapisanie wszystkich plików pośrednich / tymczasowych do osobnego katalogu ( patrz tutaj ), abyś mógł je łatwo oddzielić.

W przeciwnym razie możesz wyczyścić folder kompilacji przez Vivado, a wszystko, co pozostanie, może zostać poddane kontroli wersji.

Proszę spojrzeć na ten wątek na forach Xilinx:

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