Jump to content

    

fguy

Участник
  • Content Count

    93
  • Joined

  • Last visited

Community Reputation

0 Обычный

About fguy

  • Rank
    Частый гость

Recent Profile Visitors

805 profile views
  1. По этой фразе ошибка прекрасно гуглится 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
  2. Вывод лога сборки идет на закладку Console в SDK. Не запаривайтесь для 102 борды со старыми вивадами - 2018.3 даже относительно 2018.2 имеет ряд полезных улучшений. Насчет 2019.1 уже не скажу - не тестил. А при повторной загрузке проекта по JTAG дурят все одинаково.
  3. Если бы вы дали сюда вывод лога сборки проекта в сдк2017 то вопрос был бы более предметным, а экстрасенсы обитают на другом форуме. Лицензия обычно "режет" новые версии, а старые должны работать.
  4. "Рисование" БД ручками меня не смущает. Больше напрягает пара недостатков редактора БД - невозможность копирования через буфер элементов БД между 2мя запущенными вивадо - проблема решается ручками но почему бы не сделать как принято у всех, а так же придирки к типу данных в data на стриме - штатное IP floating point выедает весь мозг требованиями обеспечить там флоат или знаковое целое - от ошибок это не спасает и только лишняя работа.
  5. Концепция подразумевает работу с шинами AXI и AXI-stream между IP ядрами, а не разворот vhdl-модуля построчно на "квадратики" БД. Вы практически подтвердили мое предположение:
  6. В "тексте" у меня только ядра написанные в HLS на C++ - создание, правка и синтез делается по ядерно в отдельной среде Vivado HLS. BD содержит как мои ядра так и штатные. Уровень автоматизации, редактор и верификатор BD желают еще много лучшего, но это гораздо удобнее чем в тексте сводить сотню-другую ядер в один проект. Для уменьшения "площади" общей картинки в бд использую объединение ряда ядер по функциональному признаку в один "кубик" (hierarchy). При правильной организации бд имеем вполне читаемую и удобоваримую схему проекта. Для генерации БД из пары-другой сотен ядер (по счетчику загрузки вивады) написать скрипт будет еще той задачкой и это для плис с 200 кFF, а в более крупных проекты будут содержать еще больше ядер. Организация работы в виваде дело сугубо личное и каждый тут сходит с ума по своему, но отходить шибко далеко от авторской концепции имхо точно не стоит. Складывается впечатление что народ упорно тащит за уши методы работы времен вертех 2-6 с исе-альдек на новые чипы и вивадо.
  7. кстати да - особо одаренные заказчики требуют полные исходники проектов включая чужие и встроенные ядра, да и передать им купленное вами ядро вы не имеете юридических прав, так что покупка заказчиком сего ядра, если оно им так надо - наиболее юридически корректное действо
  8. Это вообще не проблема - закладываете в смету цену за IP SATA (это где то в среднем 10 к$) + ваши накладные = итого лимон деревянных сверху и пусть он сам решает чего хочет. Стоимость и сроки разработки такого IP здесь уже народ ранее расценивал в минимум человеко-год - при наших зарплатах это обойдется еще дороже чем покупать готовое, да и найти такого человека-на-год будет еще не так просто. Либо меняйте плис на UltraZynq - аналогичной емкости CG обойдутся дороже + переделка схемы, платы и софта плис и процессора.
  9. Под 7й цинк IP SATA только за денюжку. Если хотите халяву то нужно перейти на NVMe M.2 - по деньгам такой SSD не шибко дороже, а по скорости может оказаться гораздо шустрее, не говоря уже про практически дармовую реализацию на плис - схемотехника и примеры проектов на разных плис см на fpgadrive.com - само собой придется поднимать линукс ну и цинки пойдут только 30-е и выше с GTx (для SATA требования те же, а по схеме разница будет только в разъеме, да и при необходимости планку с SSD М.2 можно припаять к несущей плате с плис без использования разъема).
  10. в вопроснике для полноты картины не хватает только пункта - ручной синтез бинарника в hex-редакторе вивада это инструмент для быстрого проектирования сложных проектов для современных плис - пользуюсь bd/hls/sdk/чипскоп - vhdl только там где иначе никак
  11. 48 GTM 58 Gb на 16 нм чипах уже в продаже https://www.xilinx.com/products/technology/high-speed-serial.html и число портов на чип в 1.5 раза больше, но это все топовые монстры - что б было чем конкурентам померяться наелся АСР портом еще на 7м цинке - все красиво на бумаге, а на деле цпу слегка напрягся и плис получила фигу по доступу в память DDR на PS - скидывайте кэш ручками на цпу и будет вам счастие
  12. DG нам просто не продадут, как и "спэйс", так что ставим "индастриалы" или Е-шки, а хбм-ы не помешали бы но при ценнике в 30 куе проще подцепить на ультракинтекс пару банков ддр4 64-бит - дешево и сердито
  13. до использования линукса дело еще не доходило, а для "прямого" программирования хватает пока и одного ядра - чаще всего это настройка и управление ядрами по командам с RS или Ethernet - все остальное делает плис
  14. Необходимость использования линукса на цинках для меня связана только с применением периферии, для которой в ядре есть готовые драйвера, а ее прямое использование грозит написанием большого объема кода. На сей момент это HD/SSD на SATA и PCIe, а так же различная внешняя периферия на USB и PCIe. Ну или когда цинк должен стать фактически ПК с полноценной ОС, дисплеем (+ GPU 3D на ультрацинке) и контролерами ввода команд оператором. Все остальные задачи решаются грамотным распределением "обязанностей" между ПЛИС и ЦПУ. До использования 2-го ядра арм-а у меня дело так и не дошло, хотя иногда казалось что уже пора.
  15. В названиях есть тип чипсета - в первых двух интел Z2520, в 3й тоже интел Z2580 - оба полудохлые 32-разрядные 2х-ядерники с парой гигов озу выпуска 2013 года