Jump to content

    

OparinVD

Свой
  • Content Count

    66
  • Joined

  • Last visited

Community Reputation

0 Обычный

About OparinVD

  • Rank
    Участник
  • Birthday 09/30/1981

Информация

  • Город
    Array

Recent Profile Visitors

749 profile views
  1. Да, нашел такой файлик, спасибо, буду иметь в виду. Команды там понятные. HDL исходники подтягиваются из внешней папки при восстановлении проекта, а при восстановлении BD - в основном create_bd_cell и connect_net. Я сейчас пробую разобраться с тиклем, который лежит в папке /ipcore/xgui/. В нем расписан собственно сам интерфейс кастомизации (страницы, группы, поля) и прописаны функции update и validate для параметров. Только вот пока не докопался до того, как эта вся механика работает, кто кого вызывает? То ли сюда и напихать все эти create_bd_cell и connect_net, то ли наоборот подключать его как библиотеку в скрипте восстановления BD и рисовать этот BD с учетом параметров из GUI...
  2. Для хранения в git я отдельно сохраняю проект в tcl и отдельно сохраняю BD в tcl. Потом в скрипт восстановления проекта добавляю source BD.tcl. Да, после этого рождается тот же самый BD, что я руками рисовал (с поправкой, конечно, на взаимной расположение BD_cell'ов)
  3. При включении XIL_IFX_TRACE едет куча информации, а при включении XIL_IFX_DEBUG на "всё" интерконнект сломался, при изменении количества интерфейсов стал вываливаться с руганью на другие параметры - неожиданно :) В любом случае, для меня это большой шаг вперед, буду развлекаться, поклон вам! Еще напоследок вопрос: namespace для IPI - ipx? или каждая корка в своем namespace живет?
  4. Вот, именно про это! И да, прочитав, основные юзер-гайды, я не нашел ничего вразумительного на этот счет. В разделе про упаковку кастомного IP написаны очевидные вещи про добавление property, его тип, зависимости и т.д., а что делать с ними дальше - не понятно. С чего начать? Как заглянуть внутрь процессов в том же axis_interconnect?
  5. Вовсе нет... Как раз наоборот, результат идентичный. Я хочу сказать, что вроде как не параметризуемый снаружи cell вполне себе меняет внутреннюю структуру и подтягивает разные исходники в зависимости от параметров... Чего-то подобного я и хочу добиться от своей корки
  6. Всё тут же перерисовывается и в сторону увеличения, и в сторону уменьшения количества. И в "закрытом" и в "раскрытом" состоянии
  7. С топ-левельным BD всё понятно, это я умею. Автосборка еще не запущена, но скрипты для нее уже готовы. Речь всё-таки о другом. Возьмем, например, стандартный axis_interconnect. Если зайти в его GUI и поиграть с настройками, то внутри будут появляться и xbar'ы, и конвертеры частоты или ширины, меняться количество портов и т.д. Как это всё происходит? Подсмотреть команду несложно. Например, для изменения количества входных портов будет так: set_property -dict [_list_ CONFIG.NUM_SI {2}] [get_bd_cells axis_interconnect_1] А дальше что? Кто и как подцепляет внутри интерконнекта дополнительный s_coupler и добавляет порт на xbar? Эта магия работает на уровне HDL или на TCL?
  8. Да, речь про IPI. Только я имел в виду, что "всё завертелось" бы не вокруг моего IP, а внутри него в результате изменений параметров через GUI корки или через распространение параметров от соседей. Хотя заметил у вас команду apply_bd_automation - взял на заметку, похоже тоже пригодится. Как-то так tcl-скрипт и технологию его "набивки" я себе и представлял. На практике руку еще не набивал, но тут хотя бы всё понятно - бери и делай. Не могу понять, как связать действия в GUI настройки корки с таким скриптом. Например, я кинул свой IPcore на канвас IPI, потом дабл-кликом зашел в GUI для его конфигурации, изменил значение property, которое меняет внутреннюю структуру моего IP, (например, для простоты меняет количество инстансов какого-нибудь субмодуля). Закрыл GUI - что происходит дальше? Как мне эти изменения передать моему скрипту? Или даже по-другому. Как пользоваться Customization Parameter'ами при упаковке IPcore? С теми параметрами, что вытащены с топ-левела HDL, всё понятно - настройка на уровне HDL и происходит. А как пользоваться дополнительными property? Они же, наверно, должны настраивать IPcore на уровне TCL? PS: по рекомендациям в соседних темах я, к сожалению, не смог заглянуть в недра стандартных корок - не разобрался. Например, понял механику того, как повесить хук на Вивадовские функции, но совершенно не понял, как с помощью этого инструмента отследить, что происходит при настройке стандартных корок... Т.е. я могу добавить в функцию что-то свое новое, но как мне это поможет заглянуть в "старое"?
  9. Приветствую всех! Давно я кручусь вокруг этой темы, много раз возвращался к похожим веткам на форуме, перечитал мануалы от 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, пошла пропаганда параметров - опять запустился тот же скрипт. Как этого добиться?
  10. Мы планируем на gitlab разворачиваться, но суть в другом... Предполагается концепция, что каждая сборка должна разворачиваться с чистого листа, на чистой виртуалке. Сразу возник вопрос, можно ли из 100 ГГб Витиса/Вивады вытащить нечто маленькое, что занимается непосредственно сборкой/синтезом/имплементацией. К примеру положить ./vivado и ./xsim в пакет .deb и ими прожевать весь проект. В общем отсечь всё, что нужно для gui и оставить только то, что надо для batch-mode. Это вообще возможно? Или всё делается по-другому?
  11. Во! Про файлы сборки-то я и забыл, на них мы вполне пересекаемся... сюда же наверно и какие-то rtl-топлевелы могут добавиться. В общем и целом тогда понятно, спасибо. а тест-бенчи для rtl у Вы на CI-сервере запускаете или локально? или наверно тут есть смысл делить модульные тесты и некий общий функциональный тест-бенч
  12. Если рассматривать целиком hw сферу, то, конечно да... У меня работающая из коробки Alveo, спалить ее своим проектом я пожалуй не смогу :)) (надо было с этого начать, пардон)
  13. Для pcb-шников встречал такую штуку: https://m.habr.com/ru/company/flipperdevices/blog/554548/ но сам не пробовал, т.к. далек от этого В том то и дело, что у меня это в голове не укладывается. Я так и сам никогда не работал и даже у других не видел... Вот и пытаюсь понять, это я отстал от времени или действительно есть принципиальные отличия между sw и hw разработчиками. Положа руку на сердце, я не смог для себя их найти... там и там текстовые исходники, из них собирается конечный продукт...
  14. Нас сейчас всего двое разработчиков в проекте. Делаем настолько разные куски, что объединяемся только при линковке Витисом наших кернелов. Вполне допускаю, что когда-то нацилимся на более близкие друг к другу задачи, возможно, нас даже станет больше... Но если работать разным людям над одним куском кода - нежелательно, откуда тогда вообще появляются merge конфликты? Есть еще источники появления проблемы?