fguy

Речь о HLS - изменив алгоритм работы ядра вам необходимо будет его пересинтезировать и соответственно пересобрать проект.

А что не так с микроблэйзом - он конфигурируется под задачу и можно свести к достаточно компактному варианту. У "дефолтного" варианта правда есть проблема - он реально не работает на тех тактах что заявлены в бенче - например для ультракинтекс более менее работает на 125 МГц вместо 300. Если нужна замена автоматам на языке высокого уровня типа С/С++, то можно попробовать и HLS - конечно вещь в себе и не без проблем и фокусов на ровном месте. Соорудить автомат средней сложности с фиксированным числом тактов на цикл и работающий на 300 МГц для тех же ультракинтексов можно легко и быстро. Бонусом работа с axis, bram, slave axi lite и master axi. Из минусов то что любое изменение алгоритма потребует переразводки проекта.

Я уже писал выше что определиться с оптимизациями и констрэйнами гораздо легче когда всем рулишь сам и проект написан от и до на VHDL/Verilog, а когда 80% это штатные ядра, для которых фэншуй оптимизаций нигде не описан совсем, остается действовать по методу перебора вариантов.

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

Failed Point пишутся в виваде на странице Project Summary в блоке Timing для Setup и Hold. Их количество ненулевое при отрицательных WNS и WHS соответственно. Не знаю как для чистого VHDL, а на штатных ядрах и хлс проекты стабильно работают и при TNS в несколько сотен и фп в пару тысяч. Я для теста переразводил с ним рабочий проект в 2018.3, который давал с Performance_ExtraTimingOpt небольшие минуса и фп - проект развелся по этим параметрам лучше, но работать перестал.

Тут кто то предлагал использовать стратегию Performance_ExploreWithRemap - она действительно относительно Performance_ExtraTimingOpt дала улучшение времянки и меньше failed point, но проект разведенный с ней просто не работал.

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

По факту разница производительности одного ядра между и5 3й серии и 9900К составила всего раза 1.5 и то на даблах, а на сингл еще меньше. Это фактически соответствует разнице в тактовых цпу и ддр. Так что да - ждать какого то жуткого прироста на одном ядре от апгрейда не приходится. За счет числа ядер и озу можно получить хороший прирост только на поядерном синтезе в виваде и то один раз при первом запуске. Тут согласен, но при условии заполнения чипа по логике более 40-50% или работе на предельных частотах, а если проект без фанатизма, то чаще всего разводится и с ExtraTimingOpt. Попытка запихнуть больше обойдется в немалые временные затраты и тут уже нужно решать на уровне проекта - стоит ли оно того или проще поставить плис побольше (зачастую на то же место без переразводки платы). Ну и опять же если вы написали весь проект сами в VHDL/Verilog, то выбрать опции оптимизации и стратегии разводки будет гораздо легче, чем когда проект в бд на 80% из штатных ядер, которым никакие примочки не помогают.

USB девайсы в винде ведут себя иногда странно, могут просто пропасть - подключаешь к одному пк и он его не видит, а другой видит. Я обычно очищаю стэк коннектов для usb программой usbdeview - чаще всего помогает и драйвера из системы удалять не нужно, но иногда требуется еще сделать перезагрузку винды. По поводу конфликтов Xilinx USB cable и STM JTAG есть подозрение что в обоих стоит FT-шка и проблемы от нее, т.к. и другие девайсы с чипом FT (USBtoUART) могут положить Xilinx JTAG.

А вы случаем в линкер-скрипте прогу в ддр не грузите? Да и воткнуть разом 2 по 4 Гбайт в 32-х разрядный микроблэйз может быть проблематично - я такое тестил через свое ядро с дма, ну и на каждый банк отдельный миг-контролер ставил.

Замедление все равно будет - сужу по опыты совместных вычислений и разводок на и9 9900 - проблема скорее всего в 2х-каналаьном ОЗУ - возможно пк с 4х-канальным озу дадут лучше результат, но они где то в 2е дороже и тактовые у тех процов ниже.

Практически оно типа есть, а типа и нет. Я в процессе переноса того проекта сделал десяток разводок с одной стратегией имплемента - в основном исправления делались в ядрах хлс из за новых "фич" компилятора. Принципиальных улучшений так и не случилось - небольшая разница легко объясняется такими же небольшими изменениями в коде ядер. Проект конечно небольшой - всего 100к лютов - тут кто то писал что ИИ проявляет себя только на миллионниках - ну-ну.

На порядок 2 ssd sata/nvme одного объема, поколения и цены не отличаются - максимум раз в 5 и то только на чтении, на записи больших объемов nvme может легко слить sata ssd. При выборе ssd m.2 nvme внимательно читайте тесты - могут быть неприятные неожиданности. SSD M.2 1 TB NVMe можно найти дешевле 10 кр, но они со своими причудами - нормальные стоят уже где то от 15 кр. Ну и обходите стороной QLC как можно дальше - это днище полное. Имплемент в виваде по умолчанию использует только 2 ядра - то что спрашивает вивада про процы в начале синтеза это только для поядерного варианта имеет смысл. Если хотите имплемент на 8 ядрах нужно в консоли TCL дать команду: set_param general.maxThreads 8 Ну и команда покажет вам сколько реально используется ядер для имплемента get_param general.maxThreads К сожалению принципиальной прибавки к скорости не будет, т.к. не все стадии имплемента используют несколько ядер.

В современных реалиях виваду может ускорить только медный стакан с жидким азотом - проку от кучи ядер на имплементе мало, на синтезе только при поядерном режиме для бд. Я за проц с максимальной тактовой, а 8 ядер и 8/16 потоков за глаза, озу 64 Гб будет чаще всего хватать, на 32 Гб 2 даже средних проекта могут не собраться разом.

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

Если NoC полностью аппаратный, то откуда тогда ресурсы плис - может вы поставили обычное ip ddr4 что скорее всего тоже возможно? Для сохранения работоспособности PS c DDR не зависимо от загрузки плис NoC+DDR должен быть полностью аппаратным и конфигурироваться с PS. Upd. Проверил на мини-проекте cips + noc с одним ддр контролером - плис развелась в 0. А софт ддр контролер это аналог старого мига для версаля, если кому встроенных не хватит или еще какие заморочки типа любви к нативному интерфейсу к ддр.

Уже можно сказать родная и на подхвате - если приживется, то будет везде в следующих поколениях плис. По факту еще один вариант реализации конвейера с широким потоком обрабатываемых данных (512 бит), что то типа операций SSE и AVX - в плис то же можно так делать, но уж очень сильно скорость зависит от сложности проекта, а здесь этот недостаток отсутствует.

Эта фишка была еще в ISE, а вивада принесла наглядность для больших проектов вместе с ростом плис. Знакомые кто работал с плис еще лет 20-25 назад вообще сидели в схематике - рисовали схему соединений элементов плис ручками - 100% заполняемость была обычной нормой. На горизонте уже очередная революция - версаль - разница его с предыдущими ZynqUS+ гораздо больше прогресса между первыми цинками и второй серией. Блок из 400 процов потребует принятия новых подходов к проектированию и программированию. Видимо xilinx пришел к выводу что универсальная матрица логики плис не всегда позволяет эффективно решать задачи, да и рост реальных частот обработки в них далек от желаемого, а ip с SSR слишком уж большие. В версалях обещают на фир-ах в блоке процов 600 МГц и в реальных проектах это частота будет сохраняться, т.к. блок процов не зависит от содержимого плисовой части. Хочешь-не-хочешь, а идти в ногу со временем приходится.

Вы мне льстите - всего то старый добрый цинк7. (4% от 100к)

Это как бы самый правильный вариант - топ является враппером для бд, который связан с пинами плис через констрэйны - можно конечно топ и ручками писать если иначе никак, например, свести в кучу врапперы одной или нескольких бд и ряда других ядер или ртл. Сейчас вроде как сделали вложенные бд (DXP), но мне пока хватает и объединения блоков (hier) - средний проект это порядка 200 ip (включая фикции типа слайсов) и разом все на экран это уже перебор. Опять же многие вещи делаются автоматом во враппере бд - например, буфера для тристэйт пинов ядра SPI будут сгенерены вивадой - вам только названия сигналов согласовать с констрэйнами останется. Конечно можно, но все придется писать ручками - имхо садомазо будет еще то. Ну и я не знаю как будет (и будет ли) работать автоматический экспорт драйверов в сдк для ядер с AXI-интерфейсами для управления с процессора, да и сам конфиг процессора то же - возможно это только в бд работает. К сожалению есть и другие крайности - например, если захотите использовать нативный интерфейс вместо акси в ядре ддр, то эта фишка доступна только в ртл, а размещение ядра ддр4 там может привести к появлению на jtag второго микроблэйза из этого ядра, который вам совсем не сдался и его придется учитывать при сборе прошивки. Чем дальше в лес, тем толще глюки... В последних вивадах заметил еще одну тенденцию - ядра для видео-обработки написаны на хлс и являются конфигурируемыми, что пока не доступно простым смертным.

В первую очередь есно за наглядность и структурированность большого проекта. На vhdl видел обе крайности - все-в-одном и "бесконечное" дерево - оба представляют собой сомнительное удовольствие для написания ручками, а про наглядность можно и не упоминать - ее тут просто нет. БД это по факту красивая надстройка над проектом типа "бесконечное" дерево, только ползать по нему самому не надо. Редактор бд все еще желает лучшего, но он намного удобнее и функциональнее "списка" с микроблэйзом в ISE. Валидация бд то же полезна, но к сожалению не всегда видит косяки и цепляется там где не должна. Для облегчения сохранения в гитах в последних вивадах сделан огромный шаг - надеюсь не последний. Про непереносимость - даже классический vhdl не всегда легко перенесется с хilinx на альтеру, да и между поколениями плис можно легко что-нибудь словить. Недавно разбирал проект от известной фирмы для их новых чипов - проект универсальный под обе оболочки - виваду и альтеру, но программер такое ощущение вылез из пещеры с ISE и пытался использовать виваду как привык - в бд были такие финты наделаны, что я был в шоке - то что можно было сделать штатными ядрами зачем то делалось на ртл без всякой надобности. С враппером в виваде все достаточно просто - язык на выбор - vhdl или verilog, а если имена пинов не полениться и присвоить одни и те же в бд и констрэйнах, то и писать его не надо - разок сгенерить - дальше само автоматом.

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

Попробовал на 2021.1 исключить всю папку ip из bd - сломался миг ддр3, вернул только подпапку с миг-ом в ip (там xci и пара prj) - бд открылась нормально - параметры у ядер на месте, проверка бд проходит без ошибок, запуск генерации "продукта" с поядерным синтезом то же выполнилась. Итого в новом формате папка ip с xci и доп файлами все же нужна, либо проверяйте сами каким еще ядрам такая чистка может навредить - xilinx решил по простому оставить все. В старых версиях они так же нужны, но так же не для всех ядер и при выполнении для бд команды "reset output product" вивада оставляет только xci, а нагенеренный мусор удаляет - в новом формате проекта его держат в папке *.gen.

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

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