fguy

Развивают не протоколы, а транспортный уровень - физические интерфейсы. По записи SSD по факту даже SATA-3 6 Гбит/c не могут переварить на длинных операциях - всего то каких то 500 Мбайт/с, а по чтению им в нем конечно тесновато уже - даже дохлый QLC на 512 Гбайт читает 1 Гбайт/с по PCEe 3.0 x2. обшибся - должно быть "арм на винде", а арм в этой винде вообще то эмулирует х86 32-х разрядный для того что бы гонять старый виндовый софт и получается у него это совсем не очень - intel houdini (эмуль арма на х86) в этом плане гораздо лучше работает на дроиде и в хромоси, в т.ч. и с кодом арм64 К сожалению реальная скорость записи на длинных файлах никогда никем не указывается и про плачевное положение дел с записью у очередного супер-накопителя мы узнаем только из мата в коментах у купивших очередную вундервафлю. А верить пиковым попугаям которые стремятся к реальной пропускной способности используемых интерфейсов дело бесполезное.

Вы как на хоботе пишите - 16 Gb/s для плис даже не вчерашний день - "заоблачные частоты" сейчас на GT это раза в 3 больше. "Память от интел" я так понимаю это их хваленные SSD на QLC - полное днище - им PCIe 4.0 как собаке 5я нога. К сожалению вляпался в их нвме 660 на 512 Гб с PCIe и проседанием скорости записи до 40-50 Мбайт/с на длинных операциях записи. С другой стороны SSD который запишет треть объема разом хотя бы на половине заявленной скорости мы еще не скоро увидим. Мелкие выпустили винду под арм на фоне торжества арм-ов в попугаях чуть ли не над и5. К сожалению эти супер арм-ы слили бородатому целерону в этой винде и единственный плюс арм-ов на х86 оказался в большем времени работы, хотя назвать такую "работу" работой под виндой никто не захочет.

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

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

Вы еще на гитхаб загляните - у интела 661 репа (половина имела активность в 2019) в основной ветке, а есть еще отдельные по андроиду (больше 100 реп) и ряду других тем, у амд 13 (тринадцать) с 5 активными.

Помнится лет 10 назад в начале нынешней эпохи смартостроения винтелу (виндовс + интел) предсказывали скорый конец благодаря торжеству арм-ов и мобильных супер осей. Интел даже струхнул под этот хайп и ринулся изобретать мобильные процы на х86. Но спустя лет 6 и к нему пришло понимание что арм фуфел, а мобильные недо-оси фуфел в квадрате. Ничего кроме кнопочного телефона смартфон так заменить и не смог и вряд ли сможет, не смотря на бешеные попугаи в бенчмарках. Опосля головокружения от чужих "успехов" интел просто забил на х86 в мобильниках, а наработки по снижению TDP пригодились в процессорах для ноутов и 2-в-1. Очередное возрождение АМД подкинуло интереса к настольным процам, но сама АМД ведет себя как ксяоми - демпингует на процах, которые как всегда имеют сомнительную совместимость с оригиналом и практически нулевую поддержку со стороны производителя. В отличии от амд интел тянет на себе приличную софтовую программу поддержки - выпускает оптимизирующие компиляторы, драйвера под линукс, андроид на х86, оптимизирует нейросети под свои процы и т.п., а амд на этом всем экономит, ну и как следствие проблем нет с их процами только на игровых пк (и то не факт). Касательно альтеры какого то серьезного слияния х86 и плис мы так и не увидели - пара ксеонов можно сказать не в счет, хотя надежды какие то были. Судя по новостям сейчас в моду опять входят матрицы из сотен RISC-процессоров c широким реконфигурируемым ALU, в т.ч. и в связке с плис (ACAP Xilinx Versal) - типа считается что для DSP и AI это оптимально-гибкое решение, но интел в эту гонку пока вроде еще не влез даже с альтерами.

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

Xilinx обновил дистрибутивы вивады и витис сегодняшним числом, но офлайн витис по прежнему не доступен.

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

Сомнительно это - у меня из 7ых стоит только артикс + Zynq, MpSOC и KU - т.е. ни одно семейство не представлено полностью

Я тоже столкнулся с этой ошибкой. Проект был успешно импортирован, но при последующих попытках открыть вылезала сия ошибка в н-ных количествах и развести его не получалось. Для теста создал новый проект и после повторного открытия получил те же ошибки. В нагрузку к ней идет ошибка формирования ядра в хлс. Проблема решилась только с третьей установки. Возможно еще не нужно ставить поддержку тестовых чипов (ES) - очень хотелось глянуть как выглядит версаль. На сей момент офлайн пакет витиса на сайте не раздают.

HLS и вивада валят ошибками Cannot identify default part - даже с нуля созданный проект в виваде так дурит - поддержка чипа установлена - видимо косяк релиза Upd решилось переустановкой

Чем дальше тем смешнее - сдк в виваде нет - совсем нет. Тепереча вивада под плис, в витис под процы. Вместо 30 Гб теперь нужно качать 60. Теперь все есть в витис - зачем оставили виваду хз.

Посмотрите какие имена присваиваются этим сигналам в топе HDL wrapper для вашего BD, т.к. именно по ним идет связывание с именами в констрэйнах

Крокодилы летают - нызэнько-нызэнько...

А где пайплайн? Что будет во время регенерации ддр? И каким образом задается адрес в памяти? Отчет по синтезу положите сюда - обсудим если интересно...

Вряд ли вам кто объяснит как с помощью "правильного описания стрима добиться pipeline трансфера" - это никак не связанные вещи. Стрим (AXI-Stream) это тип шины ввода-вывода. Пайплайн обеспечивается циклом и прагмами к этому циклу, ну и в данном примере периодом записи слов в ддр - если период будет большой, то пайплайна с берстом не будет. скажите с какой скоростью вам надо писать и какая память ддр (частота, ширина и контролер цпу или плис) и я вам скажу успеете или нет

Я до недавнего времени и сам писал по старинке (как было принято в первых версиях HLS 2014) пока новый синтезатор не начал посылать. Оба варианта можно посмотреть в моем вопросе к кзаленсу https://forums.xilinx.com/t5/High-Level-Synthesis-HLS/Cycle-synthesis-error-in-Vivado-HLS-2018-2-amp-3/m-p/951573

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

В атаче вхдл ядра копировщика между двумя акси-мастерами (64 бит данные) с управлением по акси лайт. Читаемость кода у хлс синтезатора еще та - ну сами напросились. mem_copy.zip

Код пишется под конкретную задачу - ширина и скорость входного потока данных на стриме, тип ддр-контролера - процессорный или плис и т.п.. Для ультрацинков будут свои особенности из за более широкого адреса. Фактически решение получается не в одном ядре, а в совокупности ядра на хлс и штатных ядер в блок дизайне с правильной настройкой параметров всех ядер. Код на си простой for (i = 0; i < count_word; i++) { Mem[addr++] = data; } А весь остальной "обвес" будет зависеть от ваших потребностей.

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

На HLS такое пишется в несколько строк.

Вы абсолютно правы и картинка на офсайте сиё полностью подтверждает - новая оболочка заменит винегрет из sdsoc, sdaccel и sdnet для "особо одаренных", использующих ускорители для вычислений на ультра вертексах. В репе xilinx уже лежат исходники библиотек и примеров от vitis. А многострадальная вивада никуда не денется.

На артиксе с микроблэйзом никак - имг придется шить отдельно и копировать своим кодом из флэшки в ддр - при условии что код для микроблэйза помещается в выделенную брам. Если брам-а для микроблэйза в достаточном объеме не выделить, то можно использовать штатный srec_bootloader для "автоматической" загрузки рабочего кода микроблэйза в ддр из флэшки, а имг разместить как константу в коде - но это практически то же самое - так же 2 прошивки во флэш и "ручное" копирование имг в заданную область. Как вариант можете дописать srec чтобы он грузил обе части прошивки в ддр сам. Ну а эльф и бит связываются в один бит в сдк, который конвертируете в прошиваемый бин под конкретную вашу флэшку. У вас в бд отсутствует контролер флэшки - без него вы ничего не дочитаете из неё!!!