fguy

Для проверки прошивки флэшки возьмите старую виваду - типа 2014.3 - на 7мых цинках в отличии от более поздних вивад ей наплевать на ваши ошибки в проектах плис и процессора - сдк от нее шьет флэшку своим кодом без использования вашего фсбл-а.

KSZ чипы не без причуд - я на другом имел проблемы - помогли китайцы https://www.cnblogs.com/protogenoi/p/9779405.html Попробуйте этот патч или поискать что то подобное для своего. Так же помогает применение софтовых патчей из еррат к этим чипам.

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

По этой фразе ошибка прекрасно гуглится https://forums.xilinx.com/t5/Embedded-Development-Tools/SDK-won-t-build-in-WIN7-errors-out/td-p/241584 https://www.xilinx.com/support/answers/67854.html

Вывод лога сборки идет на закладку Console в SDK. Не запаривайтесь для 102 борды со старыми вивадами - 2018.3 даже относительно 2018.2 имеет ряд полезных улучшений. Насчет 2019.1 уже не скажу - не тестил. А при повторной загрузке проекта по JTAG дурят все одинаково.

Если бы вы дали сюда вывод лога сборки проекта в сдк2017 то вопрос был бы более предметным, а экстрасенсы обитают на другом форуме. Лицензия обычно "режет" новые версии, а старые должны работать.

"Рисование" БД ручками меня не смущает. Больше напрягает пара недостатков редактора БД - невозможность копирования через буфер элементов БД между 2мя запущенными вивадо - проблема решается ручками но почему бы не сделать как принято у всех, а так же придирки к типу данных в data на стриме - штатное IP floating point выедает весь мозг требованиями обеспечить там флоат или знаковое целое - от ошибок это не спасает и только лишняя работа.

Концепция подразумевает работу с шинами AXI и AXI-stream между IP ядрами, а не разворот vhdl-модуля построчно на "квадратики" БД. Вы практически подтвердили мое предположение:

В "тексте" у меня только ядра написанные в HLS на C++ - создание, правка и синтез делается по ядерно в отдельной среде Vivado HLS. BD содержит как мои ядра так и штатные. Уровень автоматизации, редактор и верификатор BD желают еще много лучшего, но это гораздо удобнее чем в тексте сводить сотню-другую ядер в один проект. Для уменьшения "площади" общей картинки в бд использую объединение ряда ядер по функциональному признаку в один "кубик" (hierarchy). При правильной организации бд имеем вполне читаемую и удобоваримую схему проекта. Для генерации БД из пары-другой сотен ядер (по счетчику загрузки вивады) написать скрипт будет еще той задачкой и это для плис с 200 кFF, а в более крупных проекты будут содержать еще больше ядер. Организация работы в виваде дело сугубо личное и каждый тут сходит с ума по своему, но отходить шибко далеко от авторской концепции имхо точно не стоит. Складывается впечатление что народ упорно тащит за уши методы работы времен вертех 2-6 с исе-альдек на новые чипы и вивадо.

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

Это вообще не проблема - закладываете в смету цену за IP SATA (это где то в среднем 10 к$) + ваши накладные = итого лимон деревянных сверху и пусть он сам решает чего хочет. Стоимость и сроки разработки такого IP здесь уже народ ранее расценивал в минимум человеко-год - при наших зарплатах это обойдется еще дороже чем покупать готовое, да и найти такого человека-на-год будет еще не так просто. Либо меняйте плис на UltraZynq - аналогичной емкости CG обойдутся дороже + переделка схемы, платы и софта плис и процессора.

Под 7й цинк IP SATA только за денюжку. Если хотите халяву то нужно перейти на NVMe M.2 - по деньгам такой SSD не шибко дороже, а по скорости может оказаться гораздо шустрее, не говоря уже про практически дармовую реализацию на плис - схемотехника и примеры проектов на разных плис см на fpgadrive.com - само собой придется поднимать линукс ну и цинки пойдут только 30-е и выше с GTx (для SATA требования те же, а по схеме разница будет только в разъеме, да и при необходимости планку с SSD М.2 можно припаять к несущей плате с плис без использования разъема).

в вопроснике для полноты картины не хватает только пункта - ручной синтез бинарника в hex-редакторе вивада это инструмент для быстрого проектирования сложных проектов для современных плис - пользуюсь bd/hls/sdk/чипскоп - vhdl только там где иначе никак

48 GTM 58 Gb на 16 нм чипах уже в продаже https://www.xilinx.com/products/technology/high-speed-serial.html и число портов на чип в 1.5 раза больше, но это все топовые монстры - что б было чем конкурентам померяться наелся АСР портом еще на 7м цинке - все красиво на бумаге, а на деле цпу слегка напрягся и плис получила фигу по доступу в память DDR на PS - скидывайте кэш ручками на цпу и будет вам счастие

DG нам просто не продадут, как и "спэйс", так что ставим "индастриалы" или Е-шки, а хбм-ы не помешали бы но при ценнике в 30 куе проще подцепить на ультракинтекс пару банков ддр4 64-бит - дешево и сердито

до использования линукса дело еще не доходило, а для "прямого" программирования хватает пока и одного ядра - чаще всего это настройка и управление ядрами по командам с RS или Ethernet - все остальное делает плис

Необходимость использования линукса на цинках для меня связана только с применением периферии, для которой в ядре есть готовые драйвера, а ее прямое использование грозит написанием большого объема кода. На сей момент это HD/SSD на SATA и PCIe, а так же различная внешняя периферия на USB и PCIe. Ну или когда цинк должен стать фактически ПК с полноценной ОС, дисплеем (+ GPU 3D на ультрацинке) и контролерами ввода команд оператором. Все остальные задачи решаются грамотным распределением "обязанностей" между ПЛИС и ЦПУ. До использования 2-го ядра арм-а у меня дело так и не дошло, хотя иногда казалось что уже пора.

Еще и разные версии его разводят по разному. Давеча переразводил проект - по лютам около 60% - в 2018.2 разводится за пару часов и с оптимизацией и без, а 2018.3 с оптимизацией на роуте в 4м пункте уходит в задумье более чем на час до вывода первой строки с оверлапами (тыщ 30) - чем кончиться ждать не стал.

https://www.xilinx.com/support/answers/66846.html https://www.xilinx.com/support/answers/67157.html https://www.xilinx.com/support/answers/71709.html поискать еще самим по emmc на https://www.xilinx.com/support/answer-navigation.html

а в чем проблемы у плис с реализацией деревьев? "компаратор" это все то же АЛУ, а полученные результаты в виде 0 и 1 как веса идут в многочлен для получения ответа - даже умножители ненужны для реализации - похожий по нагрузке поиск нескольких максимумов в потоке прекрасно работает на плис в пайплайне "дерево решений" напоминает почивший за 30 лет пролог - что то я сомневаюсь что замена слов на цифры что то принципиально изменит и писать эти деревья ручками кто то упрется

насколько понимаю "качество распознавание" сейчас делают на ИИ, да и препроцессинг делают там же в первых слоях, благо большинство функций это все тот же "высокоинтеллектуальный" многочлен - в этом направлении тот же xilinx не стоит на месте и представил Версаль, который окромя плис будет содержать сотни (128-400) процов с широким реконфигурируемым АЛУ 512 бит для решения задач в т.ч. и AI Не очень понимаю в каком месте вы увидели в плис "недостаток производительности" для ИИ? Существующие фрэймворки влезают в современную плис среднего класса и показывают производительность и энергоэффективность на зависть всем цпу и гпу. тенденция на уход от "чистой" плис к сборке с набором "железной" периферии радует - это позволяет освободить ресурсы плис для решения пользовательских задач, а не на реализацию кабы-каких микроконтролеров, недоядер контролеров ДДР, видеокодеков и т.п.

большинство функций и так работают в стриме на частотах видеопотока - зачем это ускорять в 100 раз?

к вашему невежеству это до сих пор делает куалком, еще ранее это делал TI, но они забили на мобильные сок у xilinx поточный скейлер в виде ip существует и работает вполне себе успешно - сам пользовался лет 5 назад, насколько он качественный судить не возьмусь обработкой изображений практически не занимаюсь но тот же xilinx для hls реализовал частично opencv

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

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