fguy

Передача данных по СЕ это даже не шина - это тупое навязывание данных мастером слэйву без учета готовности последнего - отсих у "классиков" кошмары на латентность и желание все сделать за один такт. По факту AXI-stream это простое расширение шины фифо с добавлением дополнительных линий (last, user, strb/keep и т.п.). Учет готовности слэйва мастером это уже смена парадигмы - вы перестаете шарахаться от латентности, можно менять интервалы обработки данных, варьируя ширину шины и частоту. Вместо потери данных, которую легко не заметить, получаете тормоза на входе конвейера, которые замечательно отслеживаются.

кзаленс уже и так изменил парадигму в виваде - от антикварных ядер с СЕ перешел на повсеместное использование акси-стримов как для дсп и видео, так и для езернета и в довесок куча ядер для удобств работы со стримами - а для написания ядер обрабатывающих стримы хлс подходит как родной

Уж лет 5 этой новинке и вполне успешно использовался в 2014 году. Понимать как работает железо нужно при любом кодинге под него. Никаких других прагм кроме PIPELINE в цикле я не добавлял, а добавление UNROLL проблему то же не решило в 2018.3 - видимо это очередной косяк синтезатора HLS. Уже заметил что в некоторых случаях 2018.3 требует написание прагм по ресурсам, которые в 2017.4 были само собой разумеющимся. Возможно и этот косяк решается каким либо хитрым сочетанием прагм. Вивадовский симулятор как раз и освоил для симуляции полученных ядер, но как уже писал выше столкнулся с неадекватностью на железе - не часто но случается.

за качество кода коллег в VHDL ни чего не скажу по причине отсутствия опыта, а в HLS иногда приходится писать полный бред на С-ях, т.к. адекватные и красивые конструкции превращаются либо в непотребное по ресурсам, либо в неработоспособное

опыт не маленький и для "классики" на VHDL отладка в альдеке была и остается штатным методом работы многая лета у коллег, но исключения увы бывают и как ни странно ни в каких то огромных проектах, а на сравнительно небольших ядрах, а синтез ядер в HLS это вообще лотерея с полным неадекватом на самом ровном месте, а результаты имплемента его творений иногда (одно радует что редко) жгут просто не по-детски - давеча пару последних вивад стошнило на простом бесконечном цикле с выводом счетчика в стрим - синтезатор hls тупо талдычит невнятную ошибку - поиск ничего не дал - видимо я первым наступил - "непосильную" задачу осилила только версия 2017.4

симуляторы судя по своему опыту с hls и коллег с VHDL имеют сомнительную ценность при текущем положении дел с имплементацией - работоспособность полученного опосля синтеза в симуляторе не дает никаких гарантий что на чипе все будет так же красиво

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

У меня окромя штатных ядер еще пара десятков своих на хлс-е и немного VHDL-ядер и все это интенсивно правится без особых проблем. Вивада при открытом БД отслеживает изменения ядер в папке репозитория и оповещает об этом с предложением обновиться, при изменениях в интерфейсах для обновленных ядер выдается предупреждение. Так что работать над проектом вполне себе удобно. Крупный проект разбивается на функциональные блоки Hierarchy, что избавляет от огромной портянки с сотней ядер в одном окне. Косяки конечно же есть как и везде - верификатор видит далеко не все проблемы, при верификации тупо упирается в несоответствие типов данных на входных стримах для IP floating_point - имхо достаточно было бы проверять ширину, жуткие тормоза при конфигурировании IP FFT и т.д.

Пользуюсь только BD с самого появления вивады (2014). Поначалу были неудобства в необходимости "ручками" раскидывать ресеты - в исе для микроблэйза это делалось автоматом. Далее с усложнением проектов стало понятно что древовидная структура в исе превратится в "дикий ужос" когда число ядер в проекте достигнет хотя бы 30-40. Сейчас в проектах число ядер доходит до 200 (по инфе вивады). Соединить это все в виде легко читаемого текста на VHDL просто не реально, а уж оперативно что то поправить и подавно. Ядро AXI Interconnect это не совсем "ядро" - это сборка из ядер которая формируется динамически из более мелких кубиков в зависимости от настроек конфигурации. Вы можете собрать ее сами, но удовольствие будет еще то. "Ядро" гигабитного эзернета это так же такая же сборка. Изменить их ручками нельзя - зато можно легко скопировать копи-пастом в свой Hierarchy. Если вы хотите использовать в БД свои исходники то оформляйте их как ядра вивады и сможете оперировать ими в БД. Сигналы интерфейсов коннектятся по именам с констрэйнами для физических пинов без всяких доп. оберток в виде топа на VHDL, а так же доступны ядра для установки ручками всяких буферов (BUFG и т.п.). Тристэйты во враппере БД автоматом прогоняются через буфера и становятся обычными inout. Копировать БД между проектами штатными средствами (через буфер копи-пастом или вивадой) возможности к сожалению нет, а ручками делается все просто - копируем папку ваш_проект.srcs\sources_1\bd\ваш_бд в другой проект в это же место и добавляем ссылку на него в файл "имя_проекта.xpr" в корне проекта. Далее открываем измененный проект и через буфер копи-пастом переносим что нужно между БД.

del

Обновил на пробу проект для цинка (кинтекс) с 2018.2 на новую. Проблем особых при конвертации не было. Заметная разница только в фифохах - изменили настройки - можно выбирать ручками как реализовывать - LUT или BRAM (может быть и URAM где есть), убрали ресеты по выходным тактам для асинхронных и добавили отключаемые счетчики, отображает итоговый размер. Так что пройтись по всем фифохам после обновления BD не помешает. Результаты разводки сравнить не получилось - фифохи поставил на автовыбор ресурса, а в результате расклад другой по BRAM и часть перешла в LUTRAM со всеми вытекающими. Время имплемента оказалось меньше минут на 15 с 1.5 часов на старой, а синтез практически не ускорился. Не смотря на отсутствие упоминания в списке обновлений, HLS все же изменился и заметно - из плюсов качество синтеза ядер улучшилось (меньше LUT, FF, времена и латентность), а из минусов теперь обязательно приходится писать прагмы по ресурсам, которые в 2018.2 были типа как само собой разумеющееся, иначе на выходе синтезатора полный неадекват.

сделайте на 3х пинах гпио - дергайте ими в нужной последовательности

Смотрите внимательно настройки ядра qspi - оно работает в одно-, двух- и 4-х канальном режиме. Если ничего не помогает - читайте даташит по ядру.

у Капитанова есть несколько открытых реализаций, но под Xilinx https://github.com/capitanov?tab=repositories

я таких баек не слышал, да и многие баги без проблем кочуют из нечетной в четную и обратно, а вот хлс колбасит не по-детски - два соседних билда могут синтезить ядра абсолютно по разному интересно будет посмотреть как они автоматизируют программирование 400 AI-процов в версале

sdk 2018.2 у меня не падает почему то и вьювер памяти не отваливается, а вот сама вивадо любит без предупреждения закрыться после выхода из чипскопа из тормозов больше всего парят настройки тяжелых ядер и особенно fft судя по репе xilinx отказывается от поквартальных билдов - упоминается 2018.3 и следом сразу 2019.1

Зачем усложнять то что давно решено с использованием плис и ддр - xilinx ip vdma с 3-мя буферами в ддр делает это на ура. Практически готовое решение расписано в рефдизайнах для досок кзаленса. Сам так конвертил цифровой видеопоток с гигабитной оптики в различные разрешения для обычных мониторов с dvi.

Стандартное решение - микроблэйз с эзернетом и ядром QSPI + софт для микроблэйза и пк. Можно сделать бин с прошивальщиком и грузить его по JTAG для обновления прошивки, а если ресурсы позволяют то встроить это в штатную прошивку. Программироваться файл 10 Мб будет где то за минуту. У этих флэшек бывает какой то странный лок, который лечится только первоначальной прошивкой в сдк - потом и свой прошивальщик работает.

на рутрэкере раздают кзалиновский сднет - может и оттуда что сгодиться

а зачем на плис вешать "сетевуху" по PCIe? по фэншую xilinx предлагается QSFP на GTY - проще и конструктивно и в плис, тем более что поток в плис сами формируете без всяких линуксов (насколько я понял)

Вы ничего не путаете - 4 Гбайта/с это уже 40 Гбитный эзернет, а не 10? DHCP вроде никто не просил пока - всем хватает статичных IP и MAC с возможностью оперативной реконфигурации - типа выдаем кучу одинаковых коробочек с одним IP и MAC по серийнику, а заказчик сам выставляет перед вводом в эксплуатацию желаемые адреса, если у него меняется адресная конфигурация сети, то он сам меняет адреса как хочет.

По своему опыту поднятия обмена по UDP без всяких там лвипов и т.п. могу сказать что чем проще тем надежнее - для того же обмена по UDP достаточно отвечать на ARP и ВСЁ - для пущего понту можно еще на простой пинг отвечать - остальное от лукавого. Генерация мультикаста UDP вообще не требует ни на что отвечать - только правильно формировать пакеты. Не нужно забывать что зачастую на плис в качестве физикалов вешаются многоканальные свитчи которые живут своей жизнью и за их поведение отвечать трудновато.

А какой смысл копать глубже - если только авторы вашего ядра ТСР не хотят получить красивый сертификат в рамочке, который ни о чем. По факту в плис отправка или прием данных в виде TCP/IP/UDP пакетов делается небольшим ядрышком в паре со штатным IP нужного эзернета, а критерием работоспособности служит правильная работа, а не сертификат в рамочке, да и реализация всех фишек протоколов и "защита от дурака" чаще всего не нужна.

у xilinx на гите есть исходники парсера тср под 10гбит на хлс https://github.com/Xilinx/HLx_Examples/tree/master/Acceleration/tcp_ip в них есть и тестбенчи для ядер - может чего там и по теме найдете

hls это непредсказуемая лотерея - то что синтезировалось и нормально отработало в симуляции в виваде - не обязательно будет работать на чипе попробуйте сделать то же самое в 2018.2 - там хлс изрядно перепилили, но некоторые вещи испортили, например, нельзя писать в элемент массива через диапазон бит - синтез ядра просто падает