[dsmv 0]

Всем доброго времени суток.

Есть такая проблема с расположением файлов для проекта Vivado. В моих проектах каталог src отделён от каталога где лежит проект Vivado. Это позволяет его легко подключить под систему контроля версий. Но при таком подходе есть проблема с IP Core. Файлы xci лежат каждый в своём каталоге, они подключены под систему контроля версий, но Vivado при своей работе начинает в этих каталогах работать. И там получается очень много файлов, что неудобно. 

Собственно вопрос - существует ли возможность указать Vivado что бы она использовала другой рабочий каталог для IP Core ?

[RobFPGA 27]

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

26 minutes ago, dsmv said:

...

Файлы xci лежат каждый в своём каталоге, они подключены под систему контроля версий, но Vivado при своей работе начинает в этих каталогах работать. И там получается очень много файлов, что неудобно. 

Отходы производства Vivado  удаляются через ignore опции в конфигурации системы контроля версий. Например у меня тоже все корки проекта создаются в отдельной папке .../src/ip_core и в ней же .gitignore

/.Xil/
/*/*/
/*/*.*
!/*/*.xci
!/*/*.prj

Соответственно в реп попадают только *.xci и *.prj файлы из всех папок IP корок создаваемых в .../ip_core.

 

Удачи! Rob.

 

 

 

[dsmv 0]

Так конечно можно, но это же надо не забыть этот файл подключить.

А как было бы хорошо, есть ip_core с файлами xci; Весь мусор в каталоге Vivado; При это с исходниками можно делать всё и очень просто. Копировать, сравнивать, архивировать, подключать под контроль версий.

[RobFPGA 27]

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

4 minutes ago, dsmv said:

Так конечно можно, но это же надо не забыть этот файл подключить.

А как было бы хорошо, есть ip_core с файлами xci; Весь мусор в каталоге Vivado; При это с исходниками можно делать всё и очень просто. Копировать, сравнивать, архивировать, подключать под контроль версий.

А чего его забывать? - один раз создал/скопировал.  У меня вообще  структура папок под проект шаблоном создается сразу со всеми служебными потрохами.   

Удачи! Rob.

 

[dxp 34]

Ещё можно хранить корки в виде тиклевых скриптов, по которым и генерить целевые xci. Мы так и делаем. У нас исходники лежат совсем отдельно от проекта вивады, который генерируется под конфигурацию (конфигураций в проекте может быть сколько угодно - наподобие как при разработке традиционного ПО заводят Release/Debug/etc конфигурации, в т.ч. могут быть конфигурации чисто для моделирования - погонять отдельные модули в своих тестбенчах).

 

Таким образом, руками редактируется и хранится под контролем директория src, где HDL исходники и директория cfg, где эн директорий, каждая из которых определяет конфигурацию (внутри лежат конфигурационные скрипты и Makefile). Для того, чтобы собрать ту или иную конфигурацию, нужно из выбранной директории запустить make <цель>, где цель - что делать: создать проект Vivado, запустить симуляцию, провести синтез и т.д. Make отрабатывает зависимости и при необходимости создаёт всё нужное - например, при запуске компиляции симулятором производится

* создание во внешней (по отношению к src и cfg) директории build, в которой в свою очередь создаются поддиректории syn, sim (для проекта Vivado и для симулятора) , а в них уже директории, одноимённые с именем конфигурации;

* генерируются xci и всё сопутствующее хозяйство, включая ip management project в build/syn/<cfg_name>/.ip/<ip_core_name>, подключаются к проекту и производится компиляция библиотек моделей этих корок, которые помещаются build/sim/<cfg_name>/simlib;

* производится компиляция проекта. 

 

После этого запускаем симулятор и даём команды на прогон. Если что-то поменялось или чего-то не хватает, система сборки (make) перегенерирует/создаст/пересоберёт необходимое. С синтезом аналогично - если нет проекта, он будет создан. Если поменялось что-то в конфигурации той или иной корки (в её тиклевом скрипте), то она будет пересобрана. Причём, не важно, запущена компиляция проекта для симулятором или синтез.

 

В этой схеме ни сам проект Vivado, ни сгенерённые IP core (xci), ни рабочее окружение симулятора никакой особой ценности не представляют - они могут быть сгенерированы за 6 секунд из конфигурации (ну, IP ядра реально не 6 секунд,  т.к. там ещё ООС синтез производится, но суть от этого не меняется). Поэтому нет никакой необходимости тащить это под контроль версий - директорию build можно без опаски снести в любой момент. Это очень удобно.

 

Ну. и легко автоматизировать сборку какого угодно количества конфигураций. Болванка проекта с этой системой сборки лежит в открытом виде на gitlab'е (ссылку могу кинуть, если интересно).

 

[Darky777 0]

4 hours ago, dxp said:

Ну. и легко автоматизировать сборку какого угодно количества конфигураций. Болванка проекта с этой системой сборки лежит в открытом виде на gitlab'е (ссылку могу кинуть, если интересно).

 

Киньте, пожалуйста. Хотелось бы посмотреть.

[dxp 34]

2 минуты назад, Darky777 сказал:

Киньте, пожалуйста. Хотелось бы посмотреть.

Репозиторий с проектом. Вытягивать надо с подмодулями (там как раз сборочные скрипты) - например, git clone --recursive. Ну, и кое-какая дока.

[dsmv 0]

8 hours ago, dxp said:

Репозиторий с проектом. Вытягивать надо с подмодулями (там как раз сборочные скрипты) - например, git clone --recursive. Ну, и кое-какая дока.

Это очень интересная система, но она нас возвращает к дискуссии что лучше использовать - сборку через скрипт или через gui.

Сборка через скрип очень полезна, особенно на удалённом сервере. Но это не удобно при оперативной работе с проектом. 

[RobFPGA 27]

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

16 hours ago, dsmv said:

Это очень интересная система, но она нас возвращает к дискуссии что лучше использовать - сборку через скрипт или через gui.

Сборка через скрип очень полезна, особенно на удалённом сервере. Но это не удобно при оперативной работе с проектом. 

Одно другому не мешает - тут важно выработать правила и методику которая будет вам удобна и покрывает ваши основные сценарии работы.

 

При работе в GUI основная головная боль это не забыть перенести изменения в скрипты. То есть  качественный экспорт проекта в tcl. Тот экспорт что есть сейчас в Vivado это такое г... но и на том спасибо. Тем более можно самому поковыряться в исходниках write_project_tcl и при желании сделать как себе хочется.  И автоматом например экспортировать все в скрипты при изменениях в GUI.  

 

Удачи! Rob

[dxp 34]

48 минут назад, dsmv сказал:

но она нас возвращает к дискуссии что лучше использовать - сборку через скрипт или через gui.

Система сборки не заставляет всё делать скриптами. Она лишь позволяет автоматизировать процесс создания проектов для синтезатора и симулятора и по желанию производить прогон в автоматическом режиме. При работе много времени проводится в GUI Vivado, но процесс создания её проекта и подключение IP ядер (с их компиляцией OOC и компиляцией библиотеки их симуляционных моделей) производится на автомате. Поскольку создание всего этого хозяйства является дешёвой в смысле трудозатрат операцией и конфигурация сама по себе является досточно компактной, то это поощряет практику создания множества конфигураций под разные конкретные контексты использования.

 

Сборка на автомате - это лишь одна из фич. При интерактивной разработке она почти не используется.

[dxp 34]

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

При работе в GUI основная головная боль это не забыть перенести изменения в скрипты. То есть  качественный экспорт проекта в tcl.

Это да, пожалуй самый "неудобный" и плохо автоматизируемый момент. Мы предпочитаем все изменения в свойствах проекта, которые нужно сохранять, сразу переносить в тиклевый конфиг. В этом вопросе помогает то, что вивада отображает все действия, производимые через GUI, в Tcl консоли. Поэтому достаточно просто скопировать нужные строчки в конфигурационный скрипт, и эти настройки будут появляться во вновь сгенерированном проекте сразу. 

 

Зато проект можно "кромсать" на экспериментах беспощадно, не боясь что-нибудь серьёзно и тем более необратимо сломать. Сталкивался с этим пару раз - наэкспериментировался так, что сборка в GUI начала глючить. Тогда просто снёс проект, сгенерил заново (при этом IP ядра пересоздавать и пересобирать не пришлось, т.к. они лежат вне внутренней структуры проекта), это заняло буквально с десяток секунд.

[RobFPGA 27]

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

57 minutes ago, dxp said:

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

Ну на самом деле не так уж и неудобно. В принципе Vivado позволяет повесить tcl хуки почти на все внутренние функции, а там уж можно такого на автоматизировать ... 

Например у меня при запуске Vivado автоматом цепляется хук на open_project  в котором при открытии проекта рядом ищется спец. файл конфигурации и автоматом подгружаются требуемые скрипты автоматизации. Точно также можно дампить конфигурацию вешая скрипты например на "STEPS.SYNTH_DESIGN.TCL.PRE" и другие события. 

Удачи! Rob.

 

[dxp 34]

9 часов назад, RobFPGA сказал:

В принципе Vivado позволяет повесить tcl хуки почти на все внутренние функции, а там уж можно такого на автоматизировать

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

[dsmv 0]

Придётся всё-таки осваивать скрипты. Пока у меня скриптами запускается моделирование в автоматизированном режиме и формирование итогового результата по запущенным тестам. Есть конечно различия в скриптах между Active-HDL и Vivdo, но работает.