OparinVD

С топ-левельным BD всё понятно, это я умею. Автосборка еще не запущена, но скрипты для нее уже готовы. Речь всё-таки о другом. Возьмем, например, стандартный axis_interconnect. Если зайти в его GUI и поиграть с настройками, то внутри будут появляться и xbar'ы, и конвертеры частоты или ширины, меняться количество портов и т.д. Как это всё происходит? Подсмотреть команду несложно. Например, для изменения количества входных портов будет так: set_property -dict [_list_ CONFIG.NUM_SI {2}] [get_bd_cells axis_interconnect_1] А дальше что? Кто и как подцепляет внутри интерконнекта дополнительный s_coupler и добавляет порт на xbar? Эта магия работает на уровне HDL или на TCL?

Да, речь про IPI. Только я имел в виду, что "всё завертелось" бы не вокруг моего IP, а внутри него в результате изменений параметров через GUI корки или через распространение параметров от соседей. Хотя заметил у вас команду apply_bd_automation - взял на заметку, похоже тоже пригодится. Как-то так tcl-скрипт и технологию его "набивки" я себе и представлял. На практике руку еще не набивал, но тут хотя бы всё понятно - бери и делай. Не могу понять, как связать действия в GUI настройки корки с таким скриптом. Например, я кинул свой IPcore на канвас IPI, потом дабл-кликом зашел в GUI для его конфигурации, изменил значение property, которое меняет внутреннюю структуру моего IP, (например, для простоты меняет количество инстансов какого-нибудь субмодуля). Закрыл GUI - что происходит дальше? Как мне эти изменения передать моему скрипту? Или даже по-другому. Как пользоваться Customization Parameter'ами при упаковке IPcore? С теми параметрами, что вытащены с топ-левела HDL, всё понятно - настройка на уровне HDL и происходит. А как пользоваться дополнительными property? Они же, наверно, должны настраивать IPcore на уровне TCL? PS: по рекомендациям в соседних темах я, к сожалению, не смог заглянуть в недра стандартных корок - не разобрался. Например, понял механику того, как повесить хук на Вивадовские функции, но совершенно не понял, как с помощью этого инструмента отследить, что происходит при настройке стандартных корок... Т.е. я могу добавить в функцию что-то свое новое, но как мне это поможет заглянуть в "старое"?

Приветствую всех! Давно я кручусь вокруг этой темы, много раз возвращался к похожим веткам на форуме, перечитал мануалы от Xilinx, но не дается оно мне. Есть ощущение, что не хватает легкого волшебного пендаля, чтоб всё встало на свои места, и чтоб над головой лампочка, как в мультике, загорелась. Что я хочу получить: Хочу навести красоту, наподобие стандартных корок - чтоб жмешь разные галочки в GUI, и в зависимости от этого подключались разные HDL-ные или IPcore-ные внутренности, и менялось, например количество внешних портов. Что умею на данные момент: 1) Могу накидать форму для GUI в IP packager'е - тут всё интуитивно понятно. Могу играть с Enablement dependency, включая/выключая порт. Вижу сгенерированный tcl-скрипт для GUI с функциями proc update_PARAM_VALUE... и proc validate_PARAM_VALUE... 2) Независимо от этого могу на основе Export Block Design создать свой скриптик, который будет с учетом внешних условностей делать create_cell'ы и соединять их connect_net'ами. Не могу понять, как мне скрестить первый и второй пункты. Сейчас у меня GUI - просто пустышка, а скрипт могу запустить только вручную, например, для восстановления проекта из git. По всей вероятности всё должно работать автоматически: кинул Ipcore на канвас, изменил параметры - запустился скрипт, который подтянул нужные исходники, создал топ-левел и т.д. Запустил валидацию BD, пошла пропаганда параметров - опять запустился тот же скрипт. Как этого добиться?

Мы планируем на gitlab разворачиваться, но суть в другом... Предполагается концепция, что каждая сборка должна разворачиваться с чистого листа, на чистой виртуалке. Сразу возник вопрос, можно ли из 100 ГГб Витиса/Вивады вытащить нечто маленькое, что занимается непосредственно сборкой/синтезом/имплементацией. К примеру положить ./vivado и ./xsim в пакет .deb и ими прожевать весь проект. В общем отсечь всё, что нужно для gui и оставить только то, что надо для batch-mode. Это вообще возможно? Или всё делается по-другому?

Во! Про файлы сборки-то я и забыл, на них мы вполне пересекаемся... сюда же наверно и какие-то rtl-топлевелы могут добавиться. В общем и целом тогда понятно, спасибо. а тест-бенчи для rtl у Вы на CI-сервере запускаете или локально? или наверно тут есть смысл делить модульные тесты и некий общий функциональный тест-бенч

Если рассматривать целиком hw сферу, то, конечно да... У меня работающая из коробки Alveo, спалить ее своим проектом я пожалуй не смогу :)) (надо было с этого начать, пардон)

Для pcb-шников встречал такую штуку: https://m.habr.com/ru/company/flipperdevices/blog/554548/ но сам не пробовал, т.к. далек от этого В том то и дело, что у меня это в голове не укладывается. Я так и сам никогда не работал и даже у других не видел... Вот и пытаюсь понять, это я отстал от времени или действительно есть принципиальные отличия между sw и hw разработчиками. Положа руку на сердце, я не смог для себя их найти... там и там текстовые исходники, из них собирается конечный продукт...

Нас сейчас всего двое разработчиков в проекте. Делаем настолько разные куски, что объединяемся только при линковке Витисом наших кернелов. Вполне допускаю, что когда-то нацилимся на более близкие друг к другу задачи, возможно, нас даже станет больше... Но если работать разным людям над одним куском кода - нежелательно, откуда тогда вообще появляются merge конфликты? Есть еще источники появления проблемы?

Всем доброго дня! Начну издалека. У нас в команде появился менеджер проектов, и недавно с ним состоялась беседа, типа: - А как вы решаете merge конфликты? - А у нас нет merge конфликтов , у нас каждый делает свой ipcore, и не бывает так, что несколько разработчиков коммитят изменения в один и тот же исходник... Потом еще долго говорили о том, что каждый должен разбираться во всём проекте, а еще нужна непрерывная интеграция и т.д. Сходу я не нашел объективных аргументов "против" кроме как "я не пробовал, но осуждаю..." Понятно, что дело это индивидуальное и завистит от многих обстоятельств,... но в своем ближайшем окружении я не знаю никого, кто в проектах на ПЛИС применял бы современные методики, всё как-то по-старинке работают. Вот я и хочу понять, это просто лень и махровый ретроград внутри каждого мешают или же CI/CD - это удел web-проектов, а в нашем цеху неприменимо? Если пользуетесь, поделитесь: - какие средства для непрерывной интеграции под проекты на ПЛИС лучше подходят? (GitLab CI/CD, Jenkins и т.д) - как выглядит маршрут CI? - какой схемы ветвления git придерживаетесь? (наверно сюда до полноты картины уместно будет) - и, наконец, возможно ли работать разным разработчикам над одним куском кода?

Нашел, прошерстил... Честно говоря, такой скрипт я уже видел, когда осваивал кунг-фу с размещением в git. Я сейчас так и делаю: сохраняю дизайн через write_tcl, сохраняю bd через "export block design" и потом корректирую скрипт дизайна, чтобы из него запускалась сборка bd. Еще недавно я и не слышал про хуки. Теперь знаю, где они живут, и даже как переименовывать tcl-функции. Очень жаль, что нельзя в пару кликов скачать ваш опыт себе в голову :)) А если серьезно, то непонятно, что делать с перехваченной функцией. Т.е. понятно, как добавить новые действия. А как с помощью этого посмотреть, что и когда запускается? А еще я понял, что совершенно не понимаю концепцию параметров в вивадо. Не приставляется палец к носу. Когда-то на первом курсе, когда я щупал Delphi, я делал свои property. Это была структурка (ну или record): одно поле - собственно значение, второе - указатель на процедуру, которая запускается, чтобы изменить значение и сделать что угодно сопутствующее. Здесь я ищу, но не нахожу нечто похожее. Наверно должна быть возможность повесить tcl на изменение параметра по аналогии с tcl.pre и tcl.post. Или конфигурационные параметры IP это просто обертка вокруг моих HDL-ных generic-ов, а вся магия творится внутри HDL с помощью for...generate? Как тогда быть, если у меня топ-левел - это wrapper для bd? Там на топе нет generic-ов. Попробовал при упаковке IP добавить параметр, но не нашел как распространить влияние этого параметра на нижестоящие части. К тому же такой параметр испаряется при следующем запуске IP packager-а

У меня пока всё хуже... Я не могу понять, куда прикручивается тикль и как его запустить на исполнение. Ткните, пожалуйста, носом

Добрый день! С прошлого раза я несколько улучшил свою "фамильярность" с TCL, пролистал UG1118. Думал, сейчас буду подглядывать в US835 и полечу высоко, но взлететь что-то так и не смог... Не могу найти, через какой механизм идет взаимодействие между топовым BD и моим кастомным IPcore. По этой же причине не могу подсмотреть, как это сделано у других. Например, при валидации я вижу предупреждения, что BD cell не принял параметр от присоединенного ядра. А как его принять, откуда мне Vivado говорит об этом? Где реализовать поведение по переконфигурации своего core? Для определенности первым шагом хочу сделать так, чтобы мой IPcore принимал значение частоты такое как у присоединенного клока в топ-левеле вместо того, которое было вбито при упаковке, а то надоело перепаковывать :)

Под стандартной схемой я как раз имею в виду набор из PCIe Endpoint, DMA и MAC статически прошитый в ПЛИС, программную прослойку из XRT и OpenCL и схему работы, когда прикладное ПО скидывает крупные блоки данных в пространство Alveo и запускает кернел на исполнение. И да, нам надо обработать данные из Ethernet, не преодолевая PCIe-барьер. По этой причине SmartNIC, (если я правильно понимаю, о чем речь) не подоходят. По крайней мере тот же SolarFlare ускоряет процесс именно за счет снижения цены преодолевания этого "барьера". А Альвео приглянулась ценой и готовым хостовым ПО. Напрямую в Xilinx не писали, мы пока через Макрогрупп пытаемся разобраться. Параллельно хочу поискать людей, у кого получились успешные пуски по нашему варианту.

Мы используем кабель QSFP -> 4xSFP+ каждый отдельный хвост это 10G В качестве тестов запускали прилагаемый бинарник, его не получится взять за основу. Но он дает понять, что вся связка U50 - кабель - 10G сетевуха работает. Схема работы через глобальную память и связку из OpenCL, XRT и т.д. понятна... но нам она нужна только как готовый "тунель" от прикладного ПО на хосте к ПЛИС. Стандартная схема предполагает, что подсистема Ethernet включена в шелл. Тогда ресурсы, относящиейся к Ethernet становятся не доступны в пользовательском RTL. Но Xilinx как раз предоставляет пример, когда и работа с XRT остается, и QSFP остается доступным. И вот этот пример у нас не работает. Прошу прощения, что сразу неточно описал

Добрый день! Уже довольно давно не можем поднять линк ethernet на Альвео U50. Соединить пытаемся Альвео и штатную сетевуху 10G. Сначала была проблема с тем, что шелл резервирует под себя ресурсы физического уровня и их нельзя использовать в пользовательском RTL. С этим, вроде, разобрались с помощью примера, выложенного в секретной части сайта Xilinx. Теперь проект собирается, но линк не встаёт. При этом при запуске example project всё едет, лампочки весело мигают, значит в железной части всё хорошо. За это время перепробовали много вариантов, катались туда обратно по версиям Vitis и операционок. Пробовали MAC с training блоком и без него, всё безрезультатно, линк не встаёт, акула данные не ловит... Складывается впечатление, что дураки не мы, а инженеры Xilinx. Но это было бы странно, за столько времени, наверно, должны бы были допилить... Кто-нибудь освоил это "оружие победы" от Xilinx? Есть успешные результаты в применении?

Проблему с "object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded" решил с помощью одного из вариантов, предложенного тут. Признаться, пользователь линукс из меня так себе, я перепробовал многие из предложенных там вариантов, но проблема решилась после перезагрузки, поэтому какой именно метод выстрелил, я не знаю. Я вообще не очень понимаю, что это было, и что я исправил. Не знаю, связано ли это с локалью, но теперь работает :) На грабли с десятичной точкой я уже тоже наступал :) Сначала думал, что проблема вызвана переездом с Windows на Убунту, но оказалось, что не компилируется даже голый example project, созданный с нуля. Решение нашел тут

Пардон, похоже, что разгадка никак не связана с дма и изернетом. Собрал новый тестовый проект с "корректным" подключением изернета, витис для него также не может построить bsp... Похоже, проблема в сообщениях, котроые я проигнорировал, т.к. не разбираясь, посчитал их следствием основной проблемы. Судя по всему, я неправильно приготовил витис под убунту... Тем не менее, мнения о подключении изернет-коре с удовольствием выслушаю :)

Всех с наступившими праздниками! Картина такая: в vivado на основе примера создан bd-проект c axi_ethernet и microblaze'ом. Из стандартной цепочки был выкинут блок dma, т.к. совершенно не нужен, данные надо пережевывать своим ртл-блоком, не дожидаясь, пока пакет доедет целиком. Витис на это ругается. Говорит, что целевая переферия подключена неправильно, что к изернету надо обязательно подключать дма или mm-fifo. 2019.2 тоже ругался на это, но, поворчав, платформу создавал, и всё работало, а тут увы... Попробовал всунуть stream broadcaster, чтобы раздвоить поток от изернета: один оставить себе, другой пустить на mm-fifo... не помогло. Обработка данных вся основана именно на стриме, поэтому городить какой-то конвертер из mm в стрим не хотелось бы. В настройках ethernet core нигде не нашел настроек, которые отвечали бы за то, какой блок должен висеть на выходе приемника изернета, но в tcl-скриптах эта проверка идет... Есть ли какое-то отворотное зелье, чтобы витис забыл про дма и mm-fifo? Вот полное ругательство Витиса:

Ух! Это ж еще одно поле не паханное! Боюсь, что в ближайшее время для моей психики будет проще считать, что "доктор сказал, ты умрешь..." :) Спасибо за науку, дальше тогда сам копать буду

А.. понял. Значит мой следующий шаг - прикрутить Моделсим как основной симулятор в Виваде и научиться его готовить. Тогда последний вопрос из области симуляторов. В свое время я его отбросил, как нечто из области фантастики, но вдруг я ошибался... Вопрос такой: могут ли современные симуляторы взаимодействовать с внешним миром кроме как через файловую систему? А именно, можно ли организовать такой стенд, где тестер накидывает пакеты через изернет и получает интерактивно ответы, но обработка идет не железе, а в модели? Или оно не стоит потраченных сил?

Ни в коем случае :) Если сравнивать с поделками из прошлой жизни, то мой текущий проект уже выглядит огромным :) И да, я уже столкнулся с болью от того, что мой Альдек не может моделировать криптованные корки новых Vivado. Пришлось вести две версии проекта: одну можно моделировать в Альдеке, вторую можно синтезировать и моделировать в Vivado, но это вызвано несовместимостью версий, как уже обсуждали весной, а не принципиальными ограничениями Альдека... Из планов на обозримое будущее - довести текущий проект до полнофункционального состояния, не задерживаясь на оптимизации. Основная цель - найти все грабли на прикладном уровне, и понять, где нужны чугунные мосты, а где ими никто пользоваться не будет. А потом займусь причесыванием, и вот там уже, надеюсь, подключу в свой арсенал все фишки SV. Можете на свой вкус порекомендовать, в сторону какого тулза смотреть? Хотелок у меня не так уж много: хочется, чтобы весь маршрут оставался в рамках одного пакета, чтобы Виваде отдать готовый проверенный кубик и запустить синтез; очень хочется FSM-рисовалку, без них прямо жизни нет :) желательна версия под Линукс

А ООП это что? Объектно-ориентированное проектирование? Я почему в сторону Ривьеры смотрю, она вроде как под Линукс должна работать. Мне сейчас пришлось ActiveHDL на виртуальной машине запускать и через папку синхронизации давать исходники Виваде. Вроде не сказать, что сильное извращение, но если получится без него, то будет лучше :)

Спасибо, принял к сведению. Займусь, как только прожую тот кусок информации, который уже пришлось отхватить за последнее время :) На сегодня миксед-сигнал мне не нужен, на потребляемых ваттах мы не экономим. Бэк-аннотейтед для себя пока тоже не вижу. Я гоняю модель на чисто функциональном уровне, потом скармливаю проект Виваде, и, если тайм-анализ сказал Ок, то я этим удовлетворен. Code-coverage в ActiveHDL видел, но не пользовался, надо будет уделить ему время. SV модули у меня написаны на средне-колхозном уровне, Альдек их спокойно переваривает и без проблем разрешает напрямую кидать на диаграмму... Значит ли это, что на данном этапе своего развития мне нет смысла пересаживаться на что-то новое? И еще вопрос: чем всё-таки отличаются ActiveHDL и Rivera? Одно является логическим развитием другого или они всё-таки для разных задач?

Соседняя тема про редакторы HDL подтолкнула меня к созданию подобной ветки про симуляторы. Я хочу выбрать для себя средство отладки так, чтобы сразу всё стало качественно и по-взрослому :) Поставить всё, что есть на рынке, опробовать и выбрать физически не возможно, хотелось бы выбрать одно направление и развивать его. Из рекламных описаний ничего не поймешь, все без сомнения лидеры индустрии, и уж с ними процесс оладки точно сократится на 90%. С сайта Альдека, например, я так и не понял, чем классический ActiveHDL отличается от Rivera'ы. Собственно, вопрос можно распространить на все тулзы: что для чего предназначено? есть только вкус и цвет или есть некая узкая (или не очень узкая) специализация каждого инструмента? По второму вопросу сначала повторюсь. Я с первого дня знакомства с ПЛИС работал с ActiveHDL. Мне функционала хватало, но я регулярно встречаю мнение, что он слабоват для верификации, и это наводит на мысли, что я что-то упускаю... Как я делаю: совсем простенькие низкоуровневые куски гоняю в интерактиве, для остального пишу тестбенч на SV. Где-то визуально анализирую результат, где-то пишу автоматическое сравнение с эталоном. Моделирует быстро, по крайней мере по сравнению с Vivado :) Отсюда вопрос: какими хотелками в области верификации полезно обзавестись разработчику? Какие фишки предлагают серьезные пакеты?

У меня всё на столе, поэтому сложности с прокси для меня чужды :) Хотя, может скоро дорасту до момента, когда целевая платформа будет воткнута в удаленный сервер. Но даже в этом виде мне сложно представить, что я буду через терминал править исходники. Скорей всего на рабочей машине останутся все привычные тулзы, а на сервер буду закидывать готовые исходники, и пусть он их пережевывает и плавит в железо. По крайней мере, так мне видится это сейчас через розовые очки :)