Jump to content

    

OparinVD

Участник
  • Content Count

    47
  • Joined

  • Last visited

Everything posted by OparinVD


  1. Под стандартной схемой я как раз имею в виду набор из PCIe Endpoint, DMA и MAC статически прошитый в ПЛИС, программную прослойку из XRT и OpenCL и схему работы, когда прикладное ПО скидывает крупные блоки данных в пространство Alveo и запускает кернел на исполнение. И да, нам надо обработать данные из Ethernet, не преодолевая PCIe-барьер. По этой причине SmartNIC, (если я правильно понимаю, о чем речь) не подоходят. По крайней мере тот же SolarFlare ускоряет процесс именно за счет снижения цены преодолевания этого "барьера". А Альвео приглянулась ценой и готовым хостовым ПО. Напрямую в Xilinx не писали, мы пока через Макрогрупп пытаемся разобраться. Параллельно хочу поискать людей, у кого получились успешные пуски по нашему варианту.
  2. Мы используем кабель QSFP -> 4xSFP+ каждый отдельный хвост это 10G В качестве тестов запускали прилагаемый бинарник, его не получится взять за основу. Но он дает понять, что вся связка U50 - кабель - 10G сетевуха работает. Схема работы через глобальную память и связку из OpenCL, XRT и т.д. понятна... но нам она нужна только как готовый "тунель" от прикладного ПО на хосте к ПЛИС. Стандартная схема предполагает, что подсистема Ethernet включена в шелл. Тогда ресурсы, относящиейся к Ethernet становятся не доступны в пользовательском RTL. Но Xilinx как раз предоставляет пример, когда и работа с XRT остается, и QSFP остается доступным. И вот этот пример у нас не работает. Прошу прощения, что сразу неточно описал
  3. Добрый день! Уже довольно давно не можем поднять линк ethernet на Альвео U50. Соединить пытаемся Альвео и штатную сетевуху 10G. Сначала была проблема с тем, что шелл резервирует под себя ресурсы физического уровня и их нельзя использовать в пользовательском RTL. С этим, вроде, разобрались с помощью примера, выложенного в секретной части сайта Xilinx. Теперь проект собирается, но линк не встаёт. При этом при запуске example project всё едет, лампочки весело мигают, значит в железной части всё хорошо. За это время перепробовали много вариантов, катались туда обратно по версиям Vitis и операционок. Пробовали MAC с training блоком и без него, всё безрезультатно, линк не встаёт, акула данные не ловит... Складывается впечатление, что дураки не мы, а инженеры Xilinx. Но это было бы странно, за столько времени, наверно, должны бы были допилить... Кто-нибудь освоил это "оружие победы" от Xilinx? Есть успешные результаты в применении?
  4. Проблему с "object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded" решил с помощью одного из вариантов, предложенного тут. Признаться, пользователь линукс из меня так себе, я перепробовал многие из предложенных там вариантов, но проблема решилась после перезагрузки, поэтому какой именно метод выстрелил, я не знаю. Я вообще не очень понимаю, что это было, и что я исправил. Не знаю, связано ли это с локалью, но теперь работает :) На грабли с десятичной точкой я уже тоже наступал :) Сначала думал, что проблема вызвана переездом с Windows на Убунту, но оказалось, что не компилируется даже голый example project, созданный с нуля. Решение нашел тут
  5. Пардон, похоже, что разгадка никак не связана с дма и изернетом. Собрал новый тестовый проект с "корректным" подключением изернета, витис для него также не может построить bsp... Похоже, проблема в сообщениях, котроые я проигнорировал, т.к. не разбираясь, посчитал их следствием основной проблемы. Судя по всему, я неправильно приготовил витис под убунту... Тем не менее, мнения о подключении изернет-коре с удовольствием выслушаю :)
  6. Всех с наступившими праздниками! Картина такая: в vivado на основе примера создан bd-проект c axi_ethernet и microblaze'ом. Из стандартной цепочки был выкинут блок dma, т.к. совершенно не нужен, данные надо пережевывать своим ртл-блоком, не дожидаясь, пока пакет доедет целиком. Витис на это ругается. Говорит, что целевая переферия подключена неправильно, что к изернету надо обязательно подключать дма или mm-fifo. 2019.2 тоже ругался на это, но, поворчав, платформу создавал, и всё работало, а тут увы... Попробовал всунуть stream broadcaster, чтобы раздвоить поток от изернета: один оставить себе, другой пустить на mm-fifo... не помогло. Обработка данных вся основана именно на стриме, поэтому городить какой-то конвертер из mm в стрим не хотелось бы. В настройках ethernet core нигде не нашел настроек, которые отвечали бы за то, какой блок должен висеть на выходе приемника изернета, но в tcl-скриптах эта проверка идет... Есть ли какое-то отворотное зелье, чтобы витис забыл про дма и mm-fifo? Вот полное ругательство Витиса:
  7. Ух! Это ж еще одно поле не паханное! Боюсь, что в ближайшее время для моей психики будет проще считать, что "доктор сказал, ты умрешь..." :) Спасибо за науку, дальше тогда сам копать буду
  8. А.. понял. Значит мой следующий шаг - прикрутить Моделсим как основной симулятор в Виваде и научиться его готовить. Тогда последний вопрос из области симуляторов. В свое время я его отбросил, как нечто из области фантастики, но вдруг я ошибался... Вопрос такой: могут ли современные симуляторы взаимодействовать с внешним миром кроме как через файловую систему? А именно, можно ли организовать такой стенд, где тестер накидывает пакеты через изернет и получает интерактивно ответы, но обработка идет не железе, а в модели? Или оно не стоит потраченных сил?
  9. Ни в коем случае :) Если сравнивать с поделками из прошлой жизни, то мой текущий проект уже выглядит огромным :) И да, я уже столкнулся с болью от того, что мой Альдек не может моделировать криптованные корки новых Vivado. Пришлось вести две версии проекта: одну можно моделировать в Альдеке, вторую можно синтезировать и моделировать в Vivado, но это вызвано несовместимостью версий, как уже обсуждали весной, а не принципиальными ограничениями Альдека... Из планов на обозримое будущее - довести текущий проект до полнофункционального состояния, не задерживаясь на оптимизации. Основная цель - найти все грабли на прикладном уровне, и понять, где нужны чугунные мосты, а где ими никто пользоваться не будет. А потом займусь причесыванием, и вот там уже, надеюсь, подключу в свой арсенал все фишки SV. Можете на свой вкус порекомендовать, в сторону какого тулза смотреть? Хотелок у меня не так уж много: хочется, чтобы весь маршрут оставался в рамках одного пакета, чтобы Виваде отдать готовый проверенный кубик и запустить синтез; очень хочется FSM-рисовалку, без них прямо жизни нет :) желательна версия под Линукс
  10. А ООП это что? Объектно-ориентированное проектирование? Я почему в сторону Ривьеры смотрю, она вроде как под Линукс должна работать. Мне сейчас пришлось ActiveHDL на виртуальной машине запускать и через папку синхронизации давать исходники Виваде. Вроде не сказать, что сильное извращение, но если получится без него, то будет лучше :)
  11. Спасибо, принял к сведению. Займусь, как только прожую тот кусок информации, который уже пришлось отхватить за последнее время :) На сегодня миксед-сигнал мне не нужен, на потребляемых ваттах мы не экономим. Бэк-аннотейтед для себя пока тоже не вижу. Я гоняю модель на чисто функциональном уровне, потом скармливаю проект Виваде, и, если тайм-анализ сказал Ок, то я этим удовлетворен. Code-coverage в ActiveHDL видел, но не пользовался, надо будет уделить ему время. SV модули у меня написаны на средне-колхозном уровне, Альдек их спокойно переваривает и без проблем разрешает напрямую кидать на диаграмму... Значит ли это, что на данном этапе своего развития мне нет смысла пересаживаться на что-то новое? И еще вопрос: чем всё-таки отличаются ActiveHDL и Rivera? Одно является логическим развитием другого или они всё-таки для разных задач?
  12. Соседняя тема про редакторы HDL подтолкнула меня к созданию подобной ветки про симуляторы. Я хочу выбрать для себя средство отладки так, чтобы сразу всё стало качественно и по-взрослому :) Поставить всё, что есть на рынке, опробовать и выбрать физически не возможно, хотелось бы выбрать одно направление и развивать его. Из рекламных описаний ничего не поймешь, все без сомнения лидеры индустрии, и уж с ними процесс оладки точно сократится на 90%. С сайта Альдека, например, я так и не понял, чем классический ActiveHDL отличается от Rivera'ы. Собственно, вопрос можно распространить на все тулзы: что для чего предназначено? есть только вкус и цвет или есть некая узкая (или не очень узкая) специализация каждого инструмента? По второму вопросу сначала повторюсь. Я с первого дня знакомства с ПЛИС работал с ActiveHDL. Мне функционала хватало, но я регулярно встречаю мнение, что он слабоват для верификации, и это наводит на мысли, что я что-то упускаю... Как я делаю: совсем простенькие низкоуровневые куски гоняю в интерактиве, для остального пишу тестбенч на SV. Где-то визуально анализирую результат, где-то пишу автоматическое сравнение с эталоном. Моделирует быстро, по крайней мере по сравнению с Vivado :) Отсюда вопрос: какими хотелками в области верификации полезно обзавестись разработчику? Какие фишки предлагают серьезные пакеты?
  13. У меня всё на столе, поэтому сложности с прокси для меня чужды :) Хотя, может скоро дорасту до момента, когда целевая платформа будет воткнута в удаленный сервер. Но даже в этом виде мне сложно представить, что я буду через терминал править исходники. Скорей всего на рабочей машине останутся все привычные тулзы, а на сервер буду закидывать готовые исходники, и пусть он их пережевывает и плавит в железо. По крайней мере, так мне видится это сейчас через розовые очки :)
  14. Перечитал ветку, и что-то у меня сова не натягивается. Половина сообщений связана с тем, умеет ли текстовый редактор делать так, чтоб было похоже на IDE. А почему тогда не IDE? С ходу, конечно, есть два очевидных ответа: 1) цена; 2) в каждом IDE есть что-то удобное, а что-то до ужаса не устраивает (Altrea c Xilinx на этот счет, похоже, вообще не парятся :) делают отличную имплементацию, а остальное - для галочки). Но меня не покидает ощущение, что я кактус не с той стороны жую... что все давно освоили волшебную связку инструментов, а я остался с динозаврами. Я пользуюсь ActiveHDL, очень нравятся его рисовалки, особенно FSM. Текстовые способности может и хуже, чем у sublime, но точно лучше, чем у Vivado. В общем, поделитесь, как вы пользуетесь отдельными редакторами, т.е как у вас выглядит связка инструментов?
  15. Честно говоря, я TCL не особо-то умею применять... Я всегда брал generic и на его основе в тексте, где надо вставлял конструкции, которые влияют на варианты синтеза, типа if ... generate и т.д. Наверно, поэтому мне сложно мозг переключить на философию xilinx. А где почитать про "конфигурируйте ваши BD через TCL скрипт "?
  16. Да, но... Скомпилированные модули должны иметь настраиваемые параметры, а BD это один из возможных вариантов при упаковке user-IP. Но получается, что я не могу создать свой настраиваемый IP на основе BD, мне остается только текстовый портмап, только хардкор! Ну или сторонние инструменты, но я пользовался только ActiveHDL, а там возникают другие проблемы... upd : опять же работу в Xilinx проделали действительно серьезную. Несмотря на то, что BD это TCL, он вполне себе умеет рыться в генериках накиданных в него компонентов и автоматически дает им нужные значения, если, например, ширина данных в цепочке конвейера разнится от компонента к компоненту... На фоне всего, что BD умеет отсутствие возможности выкинуть параметр наверх выглядит как умышленное решение, а не как увиливание от заморочек (imho :) )
  17. Спасибо! Очень жаль, что вариантов нет... Вручную портмапить тоже удовольствие сомнительное. Всё-таки у блок-дизайна есть несомненно вкусные плюшки, типа соединения сразу целыми интерфейсами, автоматической настройки параметров стандартных корок и т.д. Но какая религия запретила им сделать генерики для блок-дизайна - не пойму :) Может что-то можно из этого получить... но наверх через блок-дизайн не выкинуть... Придется действительно сигналами заводить, это, конечно, не так изящно как, например (for i... generate), но сработает
  18. Доброго дня! Вопрос, как я понял, довольно частый, но ответа я так и не нашел. Суть простая: в блок-дизайне я создаю компонент, который будет вставлен на топ-левел в виде нескольких копий, у каждой копии будет свой порядковый номер. Этот номер должен распространиться на нижестоящие компоненты в блок-дизайне, чтобы они знали, в канале с каким номером они работают. Вивадо вроде как при упаковке ip-core находит все топ-левел генерики и отображает их как настраиваемые параметры. Всё было бы хорошо, если бы у меня был текстовый топ-левел, а вот в блок-дизайне я нигде не найду как поместить такой генерик. Пока вижу единственный выход - это взять vhd-файл который отображает структуру блок-дизайна и вручную добавить в него топ-левел генерик и спортмапить его на все нижестоящие компоненты. Но это же дикий головняк! При любом телодвижении этот файл перезапишется - и начинай сначала... Как этим правильно пользоваться? Может философия Xilinx шагнула уже далеко вперед, и по их концепции это уже не требуется, а я не так всё понимаю?
  19. Честно говоря, я предполагал что ip интегратор - это аналог block diagram в active-hdl. Но судя по всему, сходства только внешние... Пробежал от пустого проекта до наполненного - не помогло. Зато явно увидел, что хотя бы clk генератор работает, раньше этого не видел, но возможно смотрел неправильно :) Поменял в sv-исходниках program на module, и vivado всё увидела и подцепила. Не знаю, с чем это связано, вроде слово program она знает, но тем не менее ноги росли именно отсюда. Теперь осталось понять, куда мне положить папочку со своими тестовыми входными данными, чтобы подцепился относительный путь для $fopen ("test_data\\raw_data.txt", "r");
  20. В настройках стоит mixed. Компиляция без проблем проходит вплоть до имплементации. На всякий случай добавил sv-файлы в основной раздел с исходниками, но т.к. там на них никто не ссылается, это ни на что не повлияло... Active-HDL галочки зеленые ставил на компилированных объектах, а тут пока не понятно, что прошло, что нет... Попробовал накидать топлевел для тестбенча в ip интеграторе, он дал добавить только топ синтезируемого проекта. Всё, что находится в разделе simulation sources кинуть на болк-дизайн не дает:Даже простые vhdl файлы типа клок-генератора не кидает. В процессе компиляции еще такие ворнинги нашел: [filemgmt 56-99] Vivado Synthesis ignores library specification for Verilog or SystemVerilog files. [HDL 9-3756] overwriting previous definition of program 'fast_valid_axis'
  21. Я вернулся в профессию после долгого перерыва. Накопилось серьезное отставание, и на всё не хватает времени, а результат как всегда нужен срочно, поэтому прошу о 5-минутном ликбезе :) Имею проект на vhdl. Для тестбенча пришлось написать два модуля на systemverilog. Все это объединено в отдельный vhdl-топлевел. В active-hdl всё работает как надо. Теперь решил прогнать это всё в вивадо 2019.1, чтобы пользоваться стандартными ip-core'ми и другими благами. Да и как ни крути, когда-то эту новую вселенную всё равно осваивать придется. Как я сделал: 1) создал проект и накидал все исходники, предназначенные для синтеза в раздел "design sources" 2) в раздел "simulation sources" накидал исходники, которые относятся только к тестбенчу (clk генератор, sv-модули, топ-левел). UUT вивадо сюда сама скопировала. Структура иерархии определилась правильно, я запускаю "behavioral simulation". 2018.2 в этом месте уходила в глубокий ступор, помогало только снятие задачи... 2019.1 "simulation step" преодолела, но варнингах написала, что "[VRFC 10-4940] 'valid_axis' remains a black box since it has no binding entity" Имена всех портов совпадают, различий в регистре нет... "Set file type" показывает systemverilog... Почитал userguide, поэкспериментировал с xvlog -sv file1.v, ни к чему не пришел В какой бубен надо виваде стукнуть, чтобы всё завелось?
  22. Спасибо за наводку! Почитал про клокинг-блоки, вроде всё понятно, тут же внедрил, но потом голову сломал, как sv-program с интерфейс-блоком вставить в топлевел на vhdl... В общем, плюнул, поставил транспортные задержки в обе стороны. #0 не помогло, а больше ноля - всё заработало. Потом уже подумал, что надо наверное было топлевел на sv сделать и не мудрить, но в тот момент че-то не сообразил. Правда, вивадо мое художество отказывается биндить и не модлирует, но это уже другая история )) Не уверен в терминологии, но речь о нетлисте. Т.е. то, что получается после компиляции hdl без привязки ни к вендору, ни к конкретным ресурсам. Самое первичное функциональное моделирование. В общем, как выше выяснилось, дело именно в race
  23. Спасибо. Честно говоря, транспортная задержка - это первое, что пришло в голову. Но мне показалось, что вставлять ее повсеместно, да к тому же на этапе функционального моделирования как-то через чур. Может тут еще где-то собака порылась? Еше немного из "истории болезни": 1) когда я пользовался только vhdl, то с подобным сталкивался, когда в тестбенче писал просто "wait for ..." И даже если этот wait совпадал по времени с тактом, это событие симулятором выставлялось в очередь перед фронтом клока. Вылечил тем, что везде, где надо стал ставить "wait until (clk='1' and clk'event)". 2) Связку vhdl-sv использую впервые. Тут также явно жду события @(posedge clk), и поначалу всё работало, как задумано. Но потом я исключил входную fifo от xilinx из цепочки TB-UUT и стал axi-стримить напрямую своему компоненту... и всё сломалось ) Вероятно, IP FIFO как раз и обеспечивало все нужные задержки, но хоть убейте, это выглядит костылем :)
  24. Всем доброго дня! Такая проблема: моделирую в Active-HDL в смешанном режиме. Для синтеза пишу на vhdl, а тестбенч на sv. Столкнулся с тем, что мой компонент uut видит управляющий сигнал, формируемый в тестбенче по @(posedge clk), не после прихода фронта clk, а в момент прямо перед фронтом. Пока писал, пост, решение уже подсказали. Поменял в тестбенче module на program. Теперь сигналы из тестбенча в uut видятся корректно, а вот в обратную сторону - по-прежнему нет. Тестбенч видит tready так, будто он установлен не в момент времени, стремящийся к фронту справа, а в момент, стремящийся к фронту слева... Как это исправить?