[fguy 5]

5 минут назад, RobFPGA сказал:

И по своему опыту могу утверждать - чем  больше FPGA тем более высокую роль играют  констрейны (в том числе и физические) как на получаемые параметры дизайна,  так и на время сборки чтобы "... заказчик не ждал"

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

[RobFPGA 35]

Приветствую!

Прожорливость синтеза HLS ( и возникающие при этом проблемы P&R) лежит в другой  плоскости  -  высокие абстракции исходного C/C++ и отличная от RTL модель потока исполнения требуют реализации блоков RTL кода  некими крупными шаблонами  которые не всегда оптимальны по ресурсам и часто плохо оптимизируются. Эта  та цена которую приходится платить за скорость  разработки. 
 

Я когда-то приводил пример - когда я начинал  работать с HSL мне пришлось насиловать в себе как RTLщика так и C/C++ программиста. Чтобы  получить  HLS код который был почти так же эффективен (по частоте) как RTL.  И  при этом достаточно сложен как C/C++.  

 

Удачи! Rob.

[fguy 5]

1 час назад, RobFPGA сказал:

Я когда-то приводил пример - когда я начинал  работать с HSL мне пришлось насиловать в себе как RTLщика так и C/C++ программиста. Чтобы  получить  HLS код который был почти так же эффективен (по частоте) как RTL.  И  при этом достаточно сложен как C/C++.

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

[blackfin 28]

3 hours ago, fguy said:

а вот лютов процента 4 (на 100к) где то сэкономила

Если 4% это 100k LUTs, то речь, видимо, о XCVU440.. Круто! На спичках уже можно не экономить.. :)

[fguy 5]

44 минуты назад, blackfin сказал:

Если 4% это 100k LUTs, то речь, видимо, о XCVU440.. Круто! На спичках уже можно не экономить.. :)

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

Изменено 5 августа, 2021 пользователем fguy

[dxp 65]

18 часов назад, fguy сказал:

возвращение к встроенным контролерам ддр для плис большой плюс - экономит кучу места (IP DDR4 до 16к LUT) и обеспечивает стабильную работу не зависимо от разводки.

Насколько я понял, немного покопав тему, DDR4 там не полностью аппаратный, аппаратный там только физический уровень (XPHY). Вся калибровка софтовая (Микроблейз стоит и рулит процессом), и сам контроллер (ядро) как и прикладной интерфейс тоже софтовые. Даже док про него называется:

 

Ну, и example project демонстрирует утилизацию:

 

откуда видно, что по нулям логических ресурсов только xphy, а всё остальное вкупе тянет примерно 10к LUT и примерно столько же флопов. Если было 16к, то вот экономия на физике. Ну, и в VM1802 таких блока 4 штуки.

 

Аппаратная физика - уже неплохой шаг вперёд, хотя в предыдущих семействах она тоже была в той или иной форме, распределена между HP банками и парой PLL из прилегающей к банку CMT (это в US). Более заметное  отличие, на мой взгляд, тут состоит в том, что XPHY конкретно вынесено в зону XPIO и туда же вытащили PLL, которые теперь называются XPLL, а CMT как таковой больше нет, MMCM отдельно живёт по соседству с DPLL (упрощенная версия с DCO вместо VCO и, соответственно, цифровым трактом управления - вместо фазового детектора и прочей аналоговой "кухни" там time-to-digital converter с аккумулятором, формирует цифровой код для управления DCO вместо аналогового напряжения в случае с VCO в PLL).

 

Ну, и доступ к контроллеру через NoC.

 

Возможно, я что-то неверно понял. В какой-то презентации попадалось, что DDR4 прямо весь аппаратный, я заинтересовался и вот покопал, но результаты раскопок скорее опровергают.

[blackfin 28]

1 hour ago, dxp said:

В какой-то презентации попадалось, что DDR4 прямо весь аппаратный

Наверное, это была презентация Versal HBM. Там и сама память DDR аппаратная.

[dxp 65]

23 минуты назад, blackfin сказал:

Наверное, это была презентация Versal HBM. Там и сама память DDR аппаратная.

Не, там такая картинка была:

 

По факту получается, что DDR4 тоже "Soft PL controller with hard PHY". Единственное у меня объяснение, что эту презентацию готовили маркетологи, могли напутать. Ну, и год стоит 2018, тема на тот момент была очень свежей, тут неточности и недоразумения являются обычным делом. Тут на  картинке даже DDR контроллеров нарисовано 6 штук, а реально их там вроде до 4-х.

[blackfin 28]

3 hours ago, dxp said:

Единственное у меня объяснение, что эту презентацию готовили маркетологи, могли напутать.

Похоже на то. Особенно если учесть, что на картинке указан довольно странный бит-рейт (4266Mb/s) для LPDDR4 памяти.

[dxp 65]

Немного смущает эта картинка:

 

 

PS через NoC попадает в DDR контроллер (своего DDR контроллера, как было в SoC'ах до сих пор, у него нет). Логики ПЛИС тут не просматривается, как будто и правда DDR контроллер полностью аппаратный. В общем, как-то это всё мутно, однозначного 100% достоверного ответа о "природе" DDR контроллера у меня нет. :(

[blackfin 28]

18 minutes ago, dxp said:

Логики ПЛИС тут не просматривается, как будто и правда DDR контроллер полностью аппаратный.

Аппаратный, но жестко привязан к Cortex-A72:

 

 

То есть, ломиться в него со стороны FPGA можно, но придется конкурировать с процессорами A72 и R5.

[dxp 65]

39 минут назад, blackfin сказал:

Аппаратный, но жестко привязан к Cortex-A72:

Это откуда следует? 

[dxp 65]

Вот накопал следующее:

 

Цитата

DDRMC
The DDRMC is a high-efficiency, low-latency integrated DDR memory controller for a variety of
applications, including general purpose central processing units (CPUs) as well as other traditional
field programmable gate array (FPGA) applications, such as video or network buffering.
The controller operates at half the DRAM clock frequency and supports DDR4, LPDDR4, and
LPDDR4X standards up to 4266 Mb/s. The controller can be configured as a single DDR memory
interface with data widths of 16, 32, and 64 bits, plus an extra 8 check bits when error-correction
code (ECC) is enabled.

 

Это ug1273. И там же есть ссылка на PG313 Versal ACAP Programmable Network on Chip and Integrated Memory Controller LogiCORE IP Product Guide. Что интересно, на странице документации по Версалям этого PG нет (потому и не нашёл). И вот в этом доке есть про этот контроллер, хотя док-то про NoC в первую очередь. В общем, немного путано, но ситуация проясняется. Похоже, что таки аппаратные там DDR4 (и про 4266 тоже подтверждают). А то, что я выше приводил, это софтовое ядро, которое цепляется к XPHY. И именно оно доступно через IP Catalog. Наравне с другими:

 

Как до аппаратного добраться, пока не понял. В PG313 есть интересные картинки:

 

Т.е. соответствует заявленному, что DDR контроллеры аппаратные, вынесены отдельно и доступ к ним сугубо через NoC как со стороны PS, так и PL (и со стороны AI тоже, вроде).

[blackfin 28]

38 minutes ago, dxp said:

Это откуда следует? 

На мой взгляд, это следует из здравого смысла.

 

Очевидно, что всем Cortex'ам непременно нужна внешняя DDR память.
Самый короткий путь к этой памяти лежит через NoC и аппаратные контроллеры DDR.

Можно, конечно, вообразить, что в PL будет синтезирован soft DDR контроллер для монопольного доступа к внешней памяти со стороны Cortex'ов, но этот путь длиннее и ест ресурсы PL:   PS->NoC->PL (soft DDR)->XPIO.

 

 

 

 

Вот ещё картинка из wp519:

[dxp 65]

Нашёл, вроде, как нему добраться. Это, оказывается, компонент AXI NoC.

 

Если в комбобоксе Memory Controller выбрать, то появляется отмеченная пачка табов про контроллер памяти.

34 минуты назад, blackfin сказал:

Вот ещё картинка из wp519:

Ещё вот такая классная картинка есть, которая тоже неплохо расставляет точки над "ё":