fguy

https://support.xilinx.com/s/article/75345?language=en_US При этом в штатных ядрах для видео этот файл используется даже в 2021.2 C:\Xilinx\Vivado\2021.2\data\ip\xilinx\v_hscaler_v1_1\src\hls_video.h Что значит не собираются? BD с ядрами на хлс собирается без проблем в 2021.2. В последних (c 2020.2) есть косяк при синтезе со штатными видеоядрами на хлс, но он лечится совсем неадекватными методами.

В последних витисах (точнее в их вивадах) есть неприятная особенность - если раньше (2018.3) на длинные пути в ядрах вивада при сборке проекта реагировала только предупреждениями, то в последних выдает ошибку и прекращает имплемент. Так что этот момент нужно учитывать при формировании структуры папок проекта, особенно если вы собираетесь использовать хлс для создания ядер. В последних витисах есть новый формат проекта (gen), когда все генерируемые вивадой файлы в srcs переносятся в папку gen, а в srcs остаются только самые необходимые файлы для описания проекта и ее полностью можно кидать в гит или т.п. Если вы собираетесь использовать последние версии витис, то эта фишка так же может пригодиться. В 2021.2 gen включается галкой в параметрах проекта.

Если не секрет то зачем вам синхронизировать TX тактами с RX - на паре цинков оно и так прекрасно работает и с "обычной" запиткой тактами RX и TX? Могу конечно и это попытаться угадать - в ответке цинку стоит какой-нибудь "российский колхоз", который не так легко адаптируется к сигналу как GTX в цинке. Для работы с SFP можно найти чипы с внешними драйверами и более широкими возможностями конфигурации (например у Cypress), но у меня в проекте оно как то не пошло - GTX для SFP это самый легкий вариант подключения.

Судя по скоростям скорее всего все делается под обычный гигабитный SFP с оптикой, а там GTX самый простой вариант подключения к SFP.

Темп данных обычно ниже выставленной скорости канала, а обмен пакетный - понятие латентности и ее снижение в таком случае теряет всякий здравый смысл. Применительно к дсп обработка в плис имеет такую латентность (один поточный бпф 8к фп32 дает 10ки тысяч тактов), что даже задержки в JESD не имеют смысла, а в задачах когда имеют проще перейти на параллельный интерфейс с цап/ацп.

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

Это же не значит что выделенные приемником такты будут 1.2 ГГц - на юзер-клок будет где-то 30-40 МГц при 32 битах данных. А в чем проблема запитать передатчик теми же тактами что и приемник - это как бы норма, тем более на одном GTX?

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

По факту это должна быть проблема продавца - при покупке вы же указываете полную спецификацию чипа - тип, корпус и спидгрэйд, а разница в цене между 1С и 2I может быть легко и в 2 раза. Если вы верите ему на "мамой клянусь" когда принимаете товар, то дальше только ваши проблемы.

Посмотрел посты конкурента от интел - там народ гораздо активнее тестит новые версии, а Xilinx за 3 года умудрился напрочь отбить желание переходить на новую версию вивады - "пичалька".

В 2018.3 SDK занимает 8 Гб, а в 2021.2 Vitis (ex SDK) - 63 Гб, из которых 40 в папке aietools - велика тяжесть искусственного интелехту

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

В альвео они вообще за копейки относительно ваших, но там спец версии чипов, на которые и даташитов нет, и в розницу они не идут. Видимо Xilinx решила хоть так что то продать для популяризации решения. С другой стороны эпл в новых М1 поставила ддр в один корпус с процом и получилось с виду неплохо - и относительно дешево, и сердито по пропускной - до 200/400 Гбайт/с при озу 32/64 Гбайт соответственно. Для сравнения сейчас один 64-х разрядный банк ддр4 2400 дает меньше 20 Гбайт/с (пиковая расчетная).

Если б не ценник на чипы в 30 куе и выше, то да, а так на порядок с лишним дешевле поставить 2 банка ддр4 на "обычную" плис. Только вот 2 ядра ддр4 с акси мастером по минимуму съедают до 20% плис типа ку60 и разводится дольше часу.

Xilinx наконец то осознал что аппаратный ддр контроллер лучше синтезируемого в плис - говорить о каких то перспективах улучшения контролера в плис не приходится - он со временем быстрее не станет и следующее поколение ддр все равно не осилит, а его размер съедает значительные ресурсы в плис + время на разводку. Но все же нативный ддр интерфейс (арр) в ряде случаев бывает быстрее, удобнее и экономнее чем AXI. То же самое касается и матрицы из VLIW процов в версалях - тактовую частоту работы для них можно получить заметно выше чем реализация в плис и тем самым выйти на новый уровень производительности и функциональности обработки данных. Имхо это будет тенденцией в развитии плис, где плисовая матрица будет связующим элементом между набором аппаратных интерфейсов и ускорителей.

Там то же куча градаций - от обычного "а ля цинк7" до грядущих версий с HBM и RFSOC, а отбраковка по процам прекрасно впишется в выкидыш "версаль артикс".

И не у вас одного. Ждем Artix Versal...

Размер дистрибутива подрос сразу на 20 Гб - до 72. Пугает слишком много букв про хлс - интересно будет посмотреть - тему совсем убили или вдруг все заработает.

Я так понимаю вам фактически нужен дма - передать/принять данные из памяти процом в/из плисовое ядро. Вы можете использовать как штатные ядра так и написать свое на хлс или vhdl/verilog. В таком случае берст по акси будет задействован. Имхо если нужно получить пакетную передачу данных в ядро, то задействовать для этого акси нет смысла - достаточно и стрима - адрес все равно в таком случае смысла не имеет - нужны только данные.

Из сдк так сделать не получится - фишка работает в хлс, но при соблюдении кучи условий - указать необходимый размер берст (пакета) по акси и делать ввод/вывод с инкрементом адреса из цикла с пайплайном 1 и латентностью не более 3. Возможно еще и в мемкопи хлс будет работать - не проверял. В сдк еще можно попытаться задействовать дма.

На цинке 7015 передавал лвипом 70 Мбайт/с на ПК - данные приходили по каналу 1 Гбит через GT, парсились в плис и записывались в ддр проца, а он уже оттуда по прерыванию готовности данных отсылал пачку udp-пакетов (1500). Имхо линукс в цинках нужен только когда используется периферия для которой писать драйвер очень сложно и долго, например, диски с sata и m.2 nvme, внешние устройства на usb и т.п.

основная рабочая все еще 2018.3, на 2021.1 то же заглядывал, но пока не все устраивает и не все работает так как хочется, хотя интересные и полезные фичи в ней все же есть - скоро уже 2021.2 должна выйти - может в ней будет еще лучше если будете откатываться на 2018.3 то там то же есть проблема с экспортом драйверов при разводке - могут экспортироваться в хдф не все драйвера - лечится патчем AR71931 - файл указан верный, а вот с описанием какой то не адекват - см описание в файле https://support.xilinx.com/s/article/71931?language=en_US

там глюк с трансляцией драйвера проца для ядра - вокурат для слэйвов, поэтому и правится через мэйкфайл https://support.xilinx.com/s/question/0D52E00006hpOx5/drivers-and-makefiles-problems-in-vitis-20202?language=en_US https://support.xilinx.com/s/article/75527?language=en_US

Если бы у вас была своя плата с физикал эзернета на плис, то задача прекрасно решается в плис - укладываете логи в udp-пакеты и отправляете мультикастом. Но у вас штатные доски и все придется передавать в проц - что бы облегчить нагрузку на проц можно так же формировать пакеты логов в плисе, загружать готовые пакеты в ддр проца и ему останется только отправить его лвипом. После загрузки данных в ддр по дма не забывайте сбрасывать кэш проца, а то данных можно и не увидеть. На 102 конечно можно поднять езернет и через sfp, но на зедборде это не возможно. К сожалению придется учесть переход проца с 32 бит на 64 - в ультрацинке у проца все указатели будут 64 бита, ну и шина адреса для процессорных AXI то же станет шире - 48 бит.

Это типа штатный глюк - с хлс ядрами те же проблемы - метод решения уйти на 2021.1 или подождать 2021.2, а с 7м цинками можно спокойно сидеть и на 2018.3. 2020.2 это какой то переходный вариант с кучей косяков - на нем лучше не задерживаться.