Перейти к содержанию
    

Как использовать Git с проектами Vivado

Всем привет!

Кто пользуется связкой Git + Vivado, подскажите, какие файлы вы держите под контролем версий, как настраиваете фильтры.

Я хочу найти сетап, который, с одной стороны, будет максимально простым, с другой стороны - держать репозиторий чистым.

 

Пока что пользуюсь таким .gitignore

Spoiler

/*.cache
/*.hw
/*.runs
/*.sim
/.Xil

*.jou
*.log

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Как-то нашёл несколько интересных решений из сети:

1. Официально от Xilinx. Наверное самый главный гайд, на который стоит ориентироваться.

https://www.xilinx.com/support/documentation/application_notes/xapp1165.pdf

2. Решение для энтузиастов. Обмазывание TCL и простынями скриптов.

https://www.srns.ru/wiki/Vivado_и_Git

3. Решение, которое мне больше всего нравится. Тоже скриптинг, но, по большей части, он запрятан вглубь.

https://ohwr.org/project/hdl-make

 

Фактически, сейчас используется официальный мануал от Xilinx с небольшими поправками.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

12 minutes ago, nice_vladi said:

Фактически, сейчас используется официальный мануал от Xilinx с небольшими поправками.

То есть, write_project_tcl каждый раз перед коммитом? А если работают одновременно несколько человек - это ж замучаешься сворачивать-разворачивать?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

7 minutes ago, pavlovconst said:

То есть, write_project_tcl каждый раз перед коммитом? А если работают одновременно несколько человек - это ж замучаешься сворачивать-разворачивать?

Да, замучаешься. Поэтому больше смотрю в сторону (3). Вообще Vivado+git это очень больно. Особенно, если есть тяга к перфекционизму.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

5 минут назад, nice_vladi сказал:

Vivado+git это очень больно

Особенно с учётом того, что в проектном режиме Вивадо каждый раз переколбашивает xpr.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приветствую!

1 hour ago, pavlovconst said:

То есть, write_project_tcl каждый раз перед коммитом? А если работают одновременно несколько человек - это ж замучаешься сворачивать-разворачивать?

А другого  универсального способа  гарантирующего  переносимость IMHO нет.  Ну  а чтобы не было  мучительно  больно многое можно автоматизировать,  тот же экспорт перед коммитом.

 

1 hour ago, nice_vladi said:

Да, замучаешься. Поэтому больше смотрю в сторону (3). Вообще Vivado+git это очень больно. Особенно, если есть тяга к перфекционизму.

Не сказал бы что уж очень  больно. Может немного неприятно по началу, пока привыкнешь  и не выработаешь  ряд полезных привычек. Одна из главных - не держать исходники в рабочей папке  проекта Vivado :unknw:    

 

Удачи! Rob. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

У нас была схожая проблема. Решалось всё относительно просто: в обычном проекте есть команда - создать tcl скрипт для проекта. В результате создаётся скрипт (кто бы мог подумать :smile:) который "билдит" проект из исходников.

Дальше всё ограничивается только правками этого скрипта. Нужно перенести все авторские файлы на папку выше, включая .xpr (несмотря на предыдущий коментарий у меня он не менялся и не переписывался) или спрятать все генерируемые файлы в отдельную папку - project. Собственно всё.

В результате получаем проект со всеми исходниками, сим-файлами, ip и т.д. + build.tcl + my_proj.xpr - это коммитим на гит. Папку project смело сносим, так как там будет только Вивадовская начинка и её можно перебилдить через build.tcl (на стартовом окне Вивады, выбрать run tcl script, оно сбилдит и откроет готовый проект).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 hour ago, RobFPGA said:

Может немного неприятно по началу, пока привыкнешь  и не выработаешь  ряд полезных привычек.

Когда в проекте периодически появляются новые разработчики - накладные расходы на "привыкание" увеличиваются (

 

Есть еще вот такой подход - фильтр по типам файлов. Но я не уверен, что он гарантирует восстановление проекта бит-в-бит

https://www.xilinx.com/support/answers/61232.html

 

1 hour ago, RobFPGA said:

Одна из главных - не держать исходники в рабочей папке  проекта Vivado :unknw:    

Поясните пож-ста, почему это важно?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приветствую!

15 minutes ago, pavlovconst said:

Когда в проекте периодически появляются новые разработчики - накладные расходы на "привыкание" увеличиваются (

IMHO. Но они (эти расходы) не идут ни в какое сравнение с потерями времени и сил  если каждый новый разработчик  будет "пилить" все по своему. :sad:

 

Удачи! Rob.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приветствую!

1 hour ago, pavlovconst said:

Поясните пож-ста, почему это важно?

Потому что в таком случае  проект не переносим через GIT. К сожалению Project Mode  в Vivado  привязан  к машине. И идеологически - многие компоненты BD/IP  динамически создаются при работе в проекта. Так и технически - абсолютными путями файлов.  И  хоть в последних  версиях с этим и пытаются бороться но не очень активно,  иногда эти абсолютные бяки вылазят  непредсказуемых местах :cray:.

 

Поэтому я для себя  давно и выработать такую структуру когда  все исходники лежать вне рабочей папки Vivado проекта.  
Когда и где мне нужно - рабочий проект создается скриптом,  все изменения в проекте перед коммитом экспортируются в скрипты (даже  отдельные BD  экспортируются отдельными скриптами). 
Можно этот экспорт ручками делать (отнимая печеньки у разработчиков если забудут :acute:), а можно повесить хуки на функции Vivado и экспортировать на любой чих в GUI - запуск синтеза|P&R, сохранение/закрытие проекта, ... 

 

При  таком раскладе  без разницы  в каком режиме  (project or non project mode) работать - можно хоть сразу в обоих. 

 

Удачи! Rob.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

14 минут назад, RobFPGA сказал:

К сожалению Project Mode  в Vivado  привязан  к машине.

Если вы имеете в виду узел в xpr

<Project Version="7" Minor="20" Path="/path/to/project.xpr">

то это никакая не привязка. path при открытии проекта меняется на ту, где этот файл расположен. И даже при миграции на альтернативную ОС.

Больше я у себя в xpr никаких абсолютных путей не вижу. Все пути определяются через $PPRDIR, $PCACHEDIR и т.д.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приветствую!

13 minutes ago, andrew_b said:

Если вы имеете в виду узел в xpr


<Project Version="7" Minor="20" Path="/path/to/project.xpr">

то это никакая не привязка. path при открытии проекта меняется на ту, где этот файл расположен. И даже при миграции на альтернативную ОС.

Больше я у себя в xpr никаких абсолютных путей не вижу. Все пути определяются через $PPRDIR, $PCACHEDIR и т.д.

Может быть, может быть. Хорошо если все так. Хотя я с 2014 версии  работаю  с внешним расположением исходников, поэтому и не замечал прогресса :unknw:
 

Удачи! Rob.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А как IP, а также BD/IP храните в гите? Особенно в non-project mode? Упаковка в .xcix + бинарно в git? Или сохранение настроек с восстановлением и пересинтезом при чекауте?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приветствую!

3 hours ago, Flood said:

А как IP, а также BD/IP храните в гите? Особенно в non-project mode? Упаковка в .xcix + бинарно в git? Или сохранение настроек с восстановлением и пересинтезом при чекауте?

Независимо от режима для IP я храню только конфиги .xci,  а BD  в виде  отдельных tcl скриптов. Зачем тащить в реп  весь автоматом  генерируемый мусор?  Ну а пере-генерировать корки на новом месте  несложно.  

 

Удачи! Rob.

 

P.S. Хотя  то что класть в реп  еще зависит и от политики  фирмы.  Бывало  что требовали держать в репе буквально все (в бинарном виде)  из чего собирается текущий  проект.  :yes3:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

5 копеек. Уже публиковали ссылку, но времени много прошло, не найти, поэтому ещё раз.

 

Мы используем систему сборки, подробно описанную тут. Там же лежит тестовый проект-"болванка", который использует эту систему, он полностью рабочий, хотя по логике почти пустой. В двух словах: проект синтезатора, скрипты для симулятора и прочее - всё это есть продукт генерации из небольшого количества конфигурационных скриптов - один makefile и несколько tcl. Вся эта конфигурация компактно хранится в своей отдельной директории. Конфигураций может быть сколько угодно (система сборки благополучно родит соответствующее количество проектов для синтеза и симулятора (хотя симулятор у нас используется в т.н. non-project mode, т.е. там по сути скрипты запуска). Новую конфигурацию очень легко склонировать из любой имеющейся путём копирования в отдельную директорию и правки makefile (обязательно) и некоторых tcl скриптов - операция несложная и нетрудоёмкая (небольшой объём правок по готовому).

 

Кстати, тема с конфигурациями очень удобна для организации, например, разработки и тестирования отдельных модулей в составе проекта - создаётся просто отдельная конфигурация, где указаны только нужные файлы (разрабатываемый исходник, тестбенч, модели и т.д.), под это система рожает проект синтезатора и симулятора. После моделирования и отладки в симе можно (и нужно) прогнать ещё и синтез (без P&R, ессно - только синтез), тут как правило вылезают свои нюансы. Проект для синтеза рожается за 6 секунд.

 

Получается, что сам по себе проект вивады никакой особой ценности не представляет - его можно прибить и родить заново тут же. Иногда так делаю, когда вивада, бывает, начинает глючить или в процессе экспериментов что-то сломал в проекте.

 

Под контроль версий, естественно попадет только директория с конфигурациями (и исходниками - они в своей директории), все эти проекты вивады и прочее - ложатся в отдельную директорию build, которая игнорируется. Итого, в историю git попадает только очень ограниченное количество небольших файлов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...