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