Я только что заявил об использовании Vivado в новом проекте и хотел бы поместить файлы проекта в SVN.

Кажется, Vivado создает все файлы проекта под именем проекта (скажем, proj1):

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

Мой вопрос: какие файлы мне нужно поместить в SVN, кроме файлов XDC и XPR?

Xilinx создаст видео YouTube (вздох), чтобы справиться с этим. Вот ссылка на видео

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

Вот мое резюме видео (8 минут)

Прежде чем ты начнешь

Если вам действительно нравится полный контроль, Xilinx предлагает полностью отказаться от GUI и делать все в командной строке, а затем вы знаете, что является источником, а что нет.

В противном случае Xilinx понимает, что проекты Vivado не предназначены для контроля версий. НЕ ПРОВЕРИТЬ ВЕСЬ ПРОЕКТ. Но продолжайте читать для подсказок ...

базисный

Конечно, все, что вы пишете вне инструмента Vivado, должно быть зарегистрировано.

Проверьте следующие файлы

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

Если вы используете блоки IP, сгенерируйте IP в уникальной папке и проверьте все.

Checkpoints

Если вы хотите иметь возможность перезапускать части потока без выполнения всего, проверьте файлы контрольных точек.

*.dcp - Design Checkpoints

Мое приложение

Если бы инструменты Xilinx были эффективными, я бы не советовал проверять файлы dcp, но для их запуска требуется очень много часов, это может быть оправдано ценой уродливой системы контроля версий.

В видео не говорится о примитивных файлах проекта Vivado (* .xpr), поэтому вот мое предложение:

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

Альтернатива, которую рекомендует Xilinx (которая на самом деле является хаком, не подходит для контроля версий), - запускать File -> Write Project Tclкоманду каждый раз, когда вы хотите зафиксировать, а затем фиксировать этот файл TCL для контроля версий. Когда вы обновляете свою локальную папку, вам нужно повторно запустить этот файл TCL, чтобы создать все файлы проекта. Тьфу.

Vivado 2014.1 позволяет использовать сценарии .tcl для регенерации проектов.

Для этого, когда ваш проект открыт, зайдите в File -> Write Project tcl.

Основные проекты

Я обычно храню свои исходники и скрипт .tcl в папке за пределами каталога проекта. Ядра xilinx IP, созданные в рамках проекта, можно скопировать в другое место, щелкнув правой кнопкой мыши ядро ​​и выбрав «Копировать IP». И удалив оригинал. Когда сценарий tcl генерируется, он создает относительные ссылки на эти файлы. Обычно так выглядит моя структура каталогов:

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

Только файлы IP .xml и .xci должны быть зафиксированы. (И даже это не является необходимым, технически, см. Примечания в конце).

Это то, что делается для git, обратите внимание на отсутствие project.xpr или каталогов проектов.

Когда я запускаю genproject.tcl, он создает другой каталог для проекта.

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

Эта новая папка полностью одноразовая. Чтобы создать эту структуру, я модифицирую скрипт tcl следующим образом.

Я изменяю первые 3 строки следующим образом:

# 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

Это создает новый каталог проекта и новый проект в этом каталоге.

Затем я изменяю пути, чтобы указать на правильные места. Возможно, вам придется изменить эти пути в других местах скрипта.

# 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

Я также изменяю дизайн прогонов для IP-ядер, как видно из этого ответа .

Файлы .wcfg могут быть включены аналогично ip и srcs.

На этом обработка заканчивается для более простых проектов (содержащих только источники и IP, без блок-схем). Для сохранения данных блок-схемы необходимо также сделать следующее.

Блок-схема проектов

Чтобы сохранить структурную схему, с открытой структурной схемой выберите Файл -> Экспорт -> Блок-схема в Tcl и сохраните ее в том же каталоге, что и другой файл tcl.

Затем я создал Generate_Wrapper.tclскрипт, который создает файлы обертки блок-схемы, поэтому вам не нужно делать это вручную. Папка project / project.srcs используется для хранения данных bd, но она по-прежнему полностью доступна, поскольку bd хранится в сценарии tcl. Сохраните это с двумя другими.

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

В конце genproject.tclя добавляю следующие строки для генерации блок-схемы и оболочек:

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

Для проектов без исходного кода (просто блок-схема) мой git commit выглядит следующим образом:

base_project/
 Generate_Wrapper.tcl
 Create_Bd.tcl
 genproject.tcl

Чтобы все сгенерировать, беги genproject.tcl.

Вы можете даже объединить все это в одно, если вы особенно эффективны, я еще не дошел до этого.

Пользовательские компоненты: проект компонента

Еще одно краткое замечание по созданию пользовательского компонента. Если у вас есть component.xml, добавьте его в список источников tcl:

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

А затем также добавьте следующий раздел:

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

Это включает в себя дизайн компонента в проект для легкой настройки.

Пользовательские компоненты: ссылка на ваш компонент

Вы можете уточнить свой путь репо своего компонента следующим образом:

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

В моей папке репо есть отдельные папки, содержащие файлы .xml. Таким образом, вы ссылаетесь не на папку, содержащую .xml, а на ее родительскую. Например:

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

Как мы запускаем эти tcl-скрипты?

Откройте Vivado и, не открывая никаких проектов, выберите Сервис -> Запустить сценарий TCL и перейдите к своему сценарию.

Дополнительные примечания TCL

Каждая команда, которую вы запускаете в Vivado, отображается в консоли tcl как команда tcl. Например, когда я сгенерировал новый IP-адрес Xilinx с помощью графического интерфейса, это появилось в консоли 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]

Это означает пару вещей:

• На самом деле вам даже не нужно сохранять ip-ядра xilinx - как только они будут такими, какими вы их хотите, скопируйте команды в скрипт tcl, и вам больше не нужно будет фиксировать ip /.

• укажите IP-каталог с аргументом -dir после -module_name, чтобы поместить его в любое место (по умолчанию он находится в project.srcs).

• В основном все, что вы делаете в графическом интерфейсе, можно сделать в tcl. Самый простой способ увидеть, как работает xilinx - это сделать это в графическом интерфейсе, а затем посмотреть, что находится в консоли TCL.

• В этом огромном PDF- файле подробно описаны все команды vivado tcl.

Существует обучающее видео Xilinx, в котором объясняется, как использовать системы контроля версий с Vivado. По сути, список файлов зависит от используемых вами функций.

Если вы используете подход на основе сценариев (как это делает vermaete), вы можете заставить Vivado записывать все промежуточные / временные файлы в отдельный каталог ( см. Здесь ), чтобы вы могли легко разделить их.

В противном случае вы можете очистить папку сборки с помощью Vivado, и все, что осталось, может быть поставлено под контроль версий.

Пожалуйста, ознакомьтесь с этой веткой на форумах Xilinx:

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