fguy

судя по тому что xilinx выпустил плис Zynq UltraScale+ EV со встроенным кодеком Н.264/265 до 4к х 2к 60 Гц делать это ip ядрами нерационально в отличии от более простых операций видеообработки типа скалинга - фирменная борда zcu104 на нем стоит всего 895 уе и в качестве бонуса hls c opencv на суперпупер-армы в смартфонах (которые к слову порвали все бенчмарки, а на деле только "баян") для решения задач видеокодеков ставят чаще всего полудохлые дсп с тактовой в разы ниже чем у ведущего арм-а, но при этом без проблем де/кодирующих пару-тройку фулхд потоков не выжирая аккумулятор

"СЕ шина" это когда на входе слэйва стоит сигнал ClockEnable и по нему он должен защелнуть данные. Ядра могут иметь право "ложить" на готовность слэйва исключительно по независящим от них причинам, например, ядро приемника GTx для физических интерфейсов не предусматривающих приостановку передаваемого потока данных (например JESD ADC) - все остальные случаи это произвол авторов. И я не спорю с тем что в таком случае слэйв должен обрабатывать каждый такт, но имея только СЕ с его стороны вы не имеете прямых методов контроля за непрерывностью процесса обработки.

Передача данных по СЕ это даже не шина - это тупое навязывание данных мастером слэйву без учета готовности последнего - отсих у "классиков" кошмары на латентность и желание все сделать за один такт. По факту 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 нужного эзернета, а критерием работоспособности служит правильная работа, а не сертификат в рамочке, да и реализация всех фишек протоколов и "защита от дурака" чаще всего не нужна.