Comments 17
полстатьи удивлялся: "почему tcl-скриптов ?"
Я не против tcl, я на нем сам писал код, но почему не python или не bash ?
А потом увидел, что у самого IDE есть туда интеграция (на скриншоте есть даже "Tcl Сonsole" внизу), он эти скрипты может исполнять "на своих батарейках" - и вопрос отпал.
Тоже писала подобный скрипт, но с опциями немедленного запуска синтеза и имплемента после разворачивания. Планировалось в дальнейшем поднять ежедневные запуски симуляции в gitlabCI.
Как будто бы не хватает папки с документацией проекта или хотя бы readme. Мы заводили для этого отдельную папочку в структуре гита и держали там все хаки проекта.
Скажите, используете ли вы в проектах ip core, которые предоставляет Xilinx? Я имею ввиду всякие FIR filter, FFT и прочее. Если да, то где храните их индивидуальные настройки, например входную-выходную ширину слов? Мне не удалось в своё время придумать ничего лучше, как хранит в гите .xci, а при сборке регенерировать из них ядра.
Немного про то, как собираемость прошивки проверяется в GitlabCI можно почитать тут: https://habr.com/en/post/673254/
IP ядра сейчас не используем (если только для дебага), т.к. проекты переносятся в итоге на ASIC
Подключается уже собранный Elf-файл для прошивки MicroBlaze (лежит в репозитории в acquisition/bin, скопированный туда руками ранее).
не очеь бьётся с
Прошивка может быть собрана в консольном режиме без применения графического интерфейса и участия человека, что позволяет включить FPGA часть проекта в контур автоматического тестирования.
В моём понимании автоматическое тестирование не должно включать в себя докопирование файлов извне репозитория, тем более руками.
Мы держали .elf в одном из сабмодулей проекта в гите. Не лучшее решение, но его поддержкой и обновлением занималась другая команда, а написать скрипт для его регенерации не дошли руки.
Что из этого списка хранить в репозитории? Что "рукописного" мы вносим в проект?
Настройки Xilinx'овских модулей в Block Diagram (.bd)
Почему вы не храните bd как tcl-скрипт? В этом случае не придется править gitignore, так как output tcl скрипта может быть полностью перенаправлен в локацию вне репозитория (там, где вы храните сгенерированные файлы, то бишь проект).
Как решатся проблема с IP ядрами? Можно версировать и смотреть diff для xci файлов, но их придется каждый раз пересобирать, что может занимать очень много времени на больших проектах. xcix пересобирать не надо, однако web diff (если у вас code-review система, типа gitlab или gerrit) для xcix не работает, потому что это архив, а не plain text. Как вы решаете эту проблему?
Tcl-скрипт для bd-файла надо было обновлять руками (нажимать кнопку в интерфейсе File->Export при открытом Block Design в IP Integrator'е). Разработчик легко может забыть это сделать после правки BD файла, дополнительный риск.
IP ядра не используем. Если самописные модули, то оформляем сабмодулями, как описано выше. Если это ядра от Xilinx, то это нас потом ограничит при переносе проекта на ASIC.
Казалось бы вот оно решение — использовать non-project подход, отличный задел для автоматизации. Но на практике разработчики его отторгают. Людям привычнее и быстрее работать в GUI.
В GUI после имплементации, если есть ошибки, можно погенерить и поизучать отчёты и посмотреть визуально, например, пути. В non-project всё менее дружелюбнее, после разводки скриптом анализировать логи надо, чтобы узнать о нарушении времянки. Поэтому тут вопрос не отторжения, а банального удобства.
При работе в non-project во-первых, в любой момент в процессе сборки (в том числе в случае ошибки) можно открыть GUI командой start_gui и тогда откроется окно аналогичное, проектному режиму. При этом можно на месте исправить некоторые ошибки и продолжить сборку дальше просто вызвав соответствующие команды в консоли. Во-вторых можно сохранять чекпоинты (.dcp файлы) в любой момент в процессе сборки и после открыть их в GUI вивады и анализировать результаты. Притом возможности аналогичные, как если бы работать в проектном режиме.
ИМХО не проектный режим просто чуть сложнее и надо курить мануалы вивады - поэтому и не популярный, но сильно упрощает работу после в плане автоматизации (в любом месте скрипта сборки можно вставить любое действие)
Согласен с предыдущим комментатором. В non-project mode (хотя там есть еще batch mode какой-то, не суть важно) надо сохранять design check point файлы (dcp) после каждого шага. Чтобы узнать о нарушении времянки достаточно просто грепнуть 'Timing Summary' табличку из timing report, это как бы вообще не препятствие.
Поэтому тут вопрос не отторжения, а банального удобства.
Это наоборот удобно. То, что заскриптовано в non-project можно сразу же использовать и в project mode. Non-project дает возможность сразу запихать проект в CI/CD, что просто must have на любом (даже небольшом) проекте.
Эх ностальгия по строму интерфейсу вивадо. Жаль автор из 2022 пишет статью по виваде 2015.3 :) Но уверен, что работать будет. Кудос тебе!
Спасибо :)
Тут скорее автор образца 2022 года репостит себя образца 2016 года по просьбам, поступившим после предыдущей статьи про автоматизирование (ага, вот это "вы часто спрашиваете меня в комментациях", когда на самом деле написал один человек)
Реализация Makefile’ов и tcl-скриптов от хабропользователя Владислава: https://github.com/vborchsh/make-fpga
Как подружить Vivado и git: с микроблейзом и сабмодулями