fguy
Свой-
Постов
382 -
Зарегистрирован
-
Посещение
Весь контент fguy
-
Новости из мира FPGA
fguy ответил x736C тема в Работаем с ПЛИС, области применения, выбор
Я не зря ссылался на маленькие плис-ы - там вы действительно еще можете решать проблемы временными констрэйнами, фиксацией размещения ядер и т.п. финтами, а сделать то же самое на чипе в пол лимона лютов займет немеренную кучу времени и сил, за которые не всякий заказчик будет готов платить и ждать. Попытки решить проблемы разводки констрэйнами для меня чаще всего имели вид какого то необъяснимого шаманства, причем рабочим решениям дивились даже те кто понимает в этом много лучше меня - по их мнению мой вариант вообще бесполезен и не должен был решить проблему, а предложенный ими вариант проблему не решал вообще. Судя по синтезатору хлс даже производитель в чудодейственные констрэйны не особо верит - при синтезе ядер под более высокие частоты используется гораздо больше ресурсов плис, а не механизм оптимизации констрэйнов - хотя при синтезе и указывается конкретная модель плис с типом корпуса и таймингом. -
Новости из мира FPGA
fguy ответил x736C тема в Работаем с ПЛИС, области применения, выбор
Когда плисы были маленькие а хотелки большие, то сия метода действительно была актуальна. Сейчас с продвижением витис сдк для вычислительных проектов временные констрэйны вообще выводятся из необходимых для написания атрибутов. Портировал проект в 2021.1 с 2018 вивады. Какого то заметного улучшения по таймингам не увидел, время имплемента то же не уменьшилось (45 мин), а вот лютов процента 4 (на 100к) где то сэкономила - может бпф-ы улучшили - хз. -
Новости из мира FPGA
fguy ответил x736C тема в Работаем с ПЛИС, области применения, выбор
Про бпф понятно что "один конь в вакууме" не актуален, но микроблэйзы тестил на пустом проекте - сам мб, эзернет и ддр и этого уже хватает что бы не работал проект на 200, а то же самое на 125 работает без проблем, хотя судя по описаниям мб должен работать на частоте акси-шины ддр ядра в плис. В их примерах мб то же выше 100 практически не используется. -
Еще нужна папка ip c файлами xci, в которых прописаны параметры используемых в бд ядер - по крайней мере в 2021.1 ее оставляют в папке srcs и в файле *.bd на них ссылаются.
-
Новости из мира FPGA
fguy ответил x736C тема в Работаем с ПЛИС, области применения, выбор
Смотрю на офсайте утилизацию на бпф и микроблэйз - заявленные частоты явно выше чем то что реально работает и не разваливается при разводке. Микроблэйз для обычного артикса заявлен 200 МГц - реально и стабильно работает 125, то же самое и ку - заявляют 300, а он даже на 200 не пашет. По бпф с флоат до 8к реально получить больше 350 что на к7, что на ку не получается. Интересные чипы даже без блока сопроцессоров. Имхо возвращение к встроенным контролерам ддр для плис большой плюс - экономит кучу места (IP DDR4 до 16к LUT) и обеспечивает стабильную работу не зависимо от разводки. Реально миллионник версаля по плис можно сравнивать с обычной плис на 1.5 лимона логики, а с блоком со-процов еще больше в зависимости от задач. Доски с ним уже вроде как доступны и открытая софтовая поддержка появилась с 2020.2. К сожалению блок сопроцов для DSP сейчас "условно полезен" - в предложенной библиотеке только фир-ы и маленькие бпф-ы (для флоат до 1к). -
2020.2 была первой реализацией и возможно глючной - проверить увы уже не смогу - снес. В 2021.1 оставил папку srcs, файл с проектом xpr и сое файл от фира - проект открылся без ошибок. Если бы не косяки в хлс, то на 2021.1 можно было бы и перейти - среда рабочая и экспорт в сдк адекватный. В 2021.1 в отличии от 2020.2 в новый формат проект можно перевести при конвертации из предыдущих версий вивад.
-
Начиная с вивады 2020.2 она хранит весь проект в папке <имя проекта>.srcs без мусора, образующегося при синтезе и далее (он вынесен наконец то в отдельную папку). Так что хранить можно ее в гит полностью + сам файл проекта. Такой вариант позволяет сразу открыть проект в первозданном виде без затрат времени на восстановлении из скриптов - у него только один недостаток - это новые версии вивады с кучей других косяков. Хранение бд в скрипте как уже писали выше ведет к переразмещению блоков "по понятиям" вивады, что не всегда удобно. При использовании внешнего репозитория с ядрами хлс, требуется их компиляции перед запуском скрипта, а это отдельный "геморой" сам по себе. Опять же скрипт для бд довольно сурово привязан к версии вивады, что то же может быть существенным.
-
Патчинг Vivado
fguy ответил RobFPGA тема в Среды разработки - обсуждаем САПРы
Под виндой вроде никаких переменных делать не нужно - вивада и так все видит - есть только требования к оформлению путей к патчу - папка должна иметь имя архива из AR (без .zip), например, C:\Xilinx\Vivado\2018.3\patches\AR71931_vivado_2018_3_preliminary_rev1_org\ Допускаю что для принятия патча нужен еще и файл C:\Xilinx\Vivado\2018.3\patches\AR71931_vivado_2018_3_preliminary_rev1_org\vivado\data\patches\AR71931.dat но он явно какой то шифрованный. Это https://www.xilinx.com/support/answers/76441.html не оно? -
Кто старое помянет - хорошо версали запускать не надо и можно сидеть в 2018.3 - там все вольности работают. В 2021.1 по крайней мере синтезит без ошибок только такой вариант без блокировок (по выходу на tready подать 1): #include "hls_stream.h" #include "ap_axi_sdata.h" typedef ap_axiu<16, 0, 0, 0> AXIS_CMD; void test_axis ( hls::stream<AXIS_CMD> &inp_cmd, hls::stream<AXIS_CMD> &out_cmd ) { #pragma HLS INTERFACE mode=axis register_mode=both port=inp_cmd register #pragma HLS INTERFACE mode=axis register_mode=both port=out_cmd register while(1) { #pragma HLS PIPELINE II=1 AXIS_CMD data_cmd; if (inp_cmd.empty()) { // Данных нет data_cmd.data = 0xA55A; } else { // Данные есть data_cmd = inp_cmd.read(); } out_cmd.write(data_cmd); } }
-
Я неблокирующее чтение делаю через обычное (блокирующее) с проверкой наличия данных inp_port.empty() - при наличии данных читаю и обрабатываю, иначе делаю что то другое. Неблокирующая запись легко меняется на блокирующую, а по выходу на tready вешается 1.
-
Дык старые вольности с описанием axis прикрыли - может поэтому и не работает - описывайте формат порта через штатные типы ap_axis/ap_axiu из ap_axi_sdata.h - может все и заработает опять.
-
По сравнению с 2020.2 в новой добавили конвертацию старого проекта в новый формат каталогов (когда в srcs только исходники проекта), а так же вернули экспорт в сдк в "старом" компактном формате (без упаковки всего проекта). К сожалению хлс продолжают гробить ударными темпами - к испорченному в 2020.2 axis добавили еще косяк с генерацией выходных портов типа ap_none.
-
Ширину шины данных для брам задает правильно, а вот параметр с размером данных в байтах формирует криво - отсих дальше валидация ругается, дает ошибку и не настраивает подключенное ядро с брамом под требуемый размер.
-
Все понятно - будьте внимательны когда читаете - в моем сообщении речь идет об интерфейсах для ядер в Vivado HLS.
-
Какие рекомендации вы имеете в виду? Можно ссылку? Используемое объявление интерфейса является штатным и прекрасно работало в хлс по 2018.3 включительно, а со следующей версии параметры интерфейса в описании ядра стали формироваться с ошибкой приводящей к последующим ошибкам в блокдизайне. Ошибка признана модераторами на форуме и якобы поставлена в какую-то очередь, где успешно пребывает до сих пор. Никаких заявлений что использование этого типа интерфейса является устаревшим или неприемлемым мне не попадалось, да и модератор форума сослался бы на них.
-
Мой любимый баг так и не починили со времен 2019.1 - пошел 3й год. Признание на их форуме багом и даже занесение в баглист для исправления со слов тамошних админов гарантирует ровным счетом ничего https://forums.xilinx.com/t5/High-Level-Synthesis-HLS/HLS-2019-x-and-2020-x-generate-incorrect-param-MEM-SIZE-for-bram/td-p/985907
-
Наконец то вышла очередная 2021.1 под все чипы...
-
Для ускорителей на ПЛИС это не адекватная цена - серия Alveo от Xilinx на офсайте от 3 k$, при том что чип на такой плате в розницу стоит на порядок дороже. В зависимости от задач вам могут подойти и новые версали, но там ценник на доску еще выше.
-
Читайте AR на офсайте - там для ряда вивад выпущены патчи для iBert https://www.xilinx.com/support/answer-navigation.html
-
что то мне подсказывает что это все же был старый-добрый шлифовальный станок, но накосячить с питанием пинов ввода/вывода, судя по форуму, наши все таки умудрились или решили упростить девайс "наши" плис обсуждают тут https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=24515
-
Китайцы и сами то как-то хитро закупили оборудование на 14 нм - вряд ли они будут его нам перепродавать - им самим сейчас срочно нужно поднять свою микроэлектронику. А свои плис еще надо разработать, а пока мы только кое как старую альтеру скопипастили. Спэйсы и милитари и у пиндосов стоят немереных денег - нам хоть бы пока индастриал продают и то хорошо.
-
По виваде 2020.2 есть тема https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=159083 К сожалению это далеко не все проблемы - на офсайте в форуме их еще больше и печаль в том что лучше как то не становится - надежд на то что очередная будет хоть как то вменяемой все меньше и меньше - пока спасает только то что с внедрением новых чипов особо не торопят.
-
Судя по гитхабу xilinx на SOM KV26 стоит новый чип xck26-sfvc784-2LV-c (или -i для индастриал) и поддержка в витис начиная с 2020.2.2 - можно только посочувствовать тем кто это будет осваивать.
-
SoC на армах это конструкторы из готовых ядер для выпуска на зарубежных фабах - их так же могут прикрыть. Китайцы вроде как наладили выпуск копий старших 7-ок (кинтекс и вертекс) xilinx - если поделятся - будем откатываться на них. Поднять свой фаб хотя бы на 14 нм для России по силам и по деньгам, но продадут ли нам оборудование - там санкции просто не кончались со времен СССР и выхлоп будет только на ВПК - ну очень дорого получится.
-
Разница в том что даташиты на такие чипы не дают и схематик на борды с ними то же. Имхо делается для того что бы не снимали и не перепродавали плисы с более дешевых плат.