[N_N 0]

Доброго времени суток!

Работаю над переделкой оного решения для PCIe без процессора, с высокоскоростными ЦАП АЦП на JESD204, DDR4 и кучей SPI периферии. Сделано Kintex UltraScale, разумеется, проект Vivado.

В нём очень много модулей с AXI4 и есть Block Design. Так вот, этот в этом Block Design очень тяжело что то делать так как очень много проводов. В частности, AXI. Хотел я разбить на иерархические блоки, в которых будет по несколько модулей, соединённых через Crossbar, а наружу пойдёт один AXI.

Сделать то это не проблема, только возник попутно вопрос - а хорошо это или плохо иметь древовидную топологию AXI, где много этих Crossbars? Надо ли стараться минимизировать их количество? Или Vivado там как то это всё оптимизирует и это всё не важно? 

[fpga_dev 11]

Я бы делал иерархически, 2, ну может 3 уровня. Оставил бы пару-тройку самых жирных/ответственных модулей на первом уровне. Собрал бы всю мелочь некритическую в отдельный блок, его и все остальное добавил бы вторым уровнем.

При этом выписал бы сначала для каждого модуля требования к траффику (bandwidth, latency) а также какие модули с какими перекрываются по времени. С тем чтобы более менее сбалансировать каждый кроссбар.

Vivado ничего особого оптимизировать не будет, но надо очень внимательно пройтись по всем настройкам всех блоков AXI и вообще следить за ним в оба а то он такого может наколбасить...

[pavlovconst 7]

@fpga_dev правильно написал, что интерконнекты могут повлиять на bandwidth и latency. Еще надо аккуратно смотреть, какую функциональность AXI4 они НЕ поддерживают. У каждого IP есть свои ограничения. Например, могут быть не поддержаны берсты, что в итоге может привести к уменьшению bandwidth и latency.

Если в вашем дизайне нет экстремальных требований по быстродействию, и характеристики кроссбаров вас устраивают, то ничего плохого в них нет. Можете строить древовидную структуру как вам удобно. У нас же цифровая электроника, в конце концов. Сигналы не затухают по пути 🙂 

[dxp 198]

И ещё надо иметь в виду, что интерконнекты эти -- довольно жирные по ресурсам блоки. Чем их меньше, тем лучше. Имхо.

[N_N 0]

Спасибо всем за рекомендации -очень полезно! 🙂

Мнда. Как чувствовал, что какой то подвох всё таки здесь есть, хотя бы с ресурсами. Ну там в основном всякие вспомогательные, контрольные интерфейсы AXI4lite, которых много. Так то, в общем, два уровня ветвления вышло.

А то что требует производительности, особо оно ещё не сделано даже. Но там можно минимизировать всякие ненужные ветвления, так и сделаю.

[fpga_dev 11]

Ах так вы об этом:) 

Для регистровых интерфейсов bandwidth обычно не проблема совсем, вопрос скорее в минимизации latency и ресурсов. И один большой блок вполне себе работает. Ветвления могут иметь смысл если у вас напр. разные блоки имеют разные типы интерфейсов (axi vs axilite), разную ширину или разные клоки. Так напр. если у вас на входе 64 или 128 бит axi а половина блоков 32 бит axilite то их имеет смысл  их сгруппировать и т д.

У нас для этих целей вообще используется самопальный генератор интерфейсов, который на основе описания регистров в yaml генерит .vhd, .h и .html. При этом вместо axi используется нечто вроде OPB, отчасти по историческим причинам, отчасти потому что даже axilite для доступа к регистрам это оверкилл, раздельные адреса для чтения и записи не нужны и только тратят ресурсы.

Но у всех все по разному, у нас регистры используются как правило только для инициализации и текущего статуса, все данные идут через SGDMA, включая дескрипторы итд. Если у вас по другому то это меняет картину.

Я-то имел в виду шину идущую в обратном направлении, когда большое количество axi мастеров все хотят доступ к DDR. Вот тут все по другому. Для многих блоков latency не настолько критична, но важна гарантированная QoS напр. для видео или сетевых потоков. Для других блоков, которые используют DDR в качестве кеша наоборот нужно минимизировать latency, для третьих просто в чистом виде  bandwidth. Вот тут и начинаются пляски с бубном.

[fguy 9]

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

[N_N 0]

Мнда.. Ну в том то и проблема, оно это ветвление не нужно, но блок-схема иначе выглядит страшно.  Вот надо что то добавить, и это боль и вырви-лаз 🤢 Попробую баланс нужен между "страшо и рационально" и " не страшно и нерационально, зато удобно и вроде работает". 😁

У меня пока нет ресурсов делать свои инструменты для этого всего, как fpga_dev писал, поэтому приходится использовать блок-схему из коробки и AXI light. Да, там многовато проводов для регистров - это да 🙂. Но все IP от Xilinx идут с AXI light для настройки, тут уж никуда не денешься. Генератор регистров использую System RDL.  

Вот в квартусе, помню, был Qsys - там это как то более удобно было сделано: просто соединяешь проводки Avalon к шине и всё, никаких дополнительный блоков не надо.  А тут какие-то кроссбары надо добавлять... Давно это было, правда, не знаю как там в квартусе сейчас.

Ну я думаю, работать будет. Но интересно было альтернативные мнения услышать, кто как делает. Может что и пригодится на будущее. А что AXI Light избыточен для регистров - ну как бы да. Но с другой стороны у меня XCKU060- там места много пока 😁.

А с DDR там своя отдельная DMA система сделана, без AXI. Потому что с AXI IP контроллера памяти генерируется только с ECC и 512бит шиной данных,  а без AXI - можно без ECC (оно там не надо), зато с 576-биттной шиной 😁, потому что ECC коды не надо записывать, а это +64 бита. Такие дела. Хочешь производительность - делай сам 🙄

[fguy 9]

2 часа назад, N_N сказал:

А тут какие-то кроссбары надо добавлять...

Самому этот делать не надо от слова совсем - все это делает мастер - нужно только автоматом назначить адреса ядрам.

2 часа назад, N_N сказал:

А с DDR там своя отдельная DMA система сделана, без AXI. Потому что с AXI IP контроллера памяти генерируется только с ECC и 512бит шиной данных,  а без AXI - можно без ECC (оно там не надо), зато с 576-биттной шиной 😁, потому что ECC коды не надо записывать, а это +64 бита. Такие дела. Хочешь производительность - делай сам

Но для этого должны быть соответствующие чипы ддр и разводка - на обычных будет 4 по 16. +64 бита хороши не на всех задачах - если писать подряд данные с ацп то конечно будет небольшой плюс, а вот как быть с линейной адресацией и все остальные шины имеют кратную степени 2ки ширину?

[N_N 0]

3 часа назад, fguy сказал:

Самому этот делать не надо от слова совсем - все это делает мастер - нужно только автоматом назначить адреса ядрам.

Но для этого должны быть соответствующие чипы ддр и разводка - на обычных будет 4 по 16. +64 бита хороши не на всех задачах - если писать подряд данные с ацп то конечно будет небольшой плюс, а вот как быть с линейной адресацией и все остальные шины имеют кратную степени 2ки ширину?

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

С отсутствием степени двойки можно порешать, не оч удобно, но можно. Они же как то сделали, значит и я сделаю 😁 Там гигасемплов много и каналов, так что, шина пошире не повредит. Там ничего хитрого с этими данными не происходит - это генератор сигналов специальный, он их берёт и суёт в ЦАПы, если по простому.

[fguy 9]

С UI на ддр4 в KU есть один неприятный сюрпрайз - если ядро ддр4 вставить в топ файл vhdl (вставить IP ддр4 с UI в BD нельзя), то сдк привидятся аж 2 микроблэйза - один обычный из BD, а другой из ддр4. Проблему решил просто - создал ядро обертку для ядра ддр4 настроенного на UI. Сам UI это по факту 3 AXI стрима.

10 часов назад, N_N сказал:

Там ничего хитрого с этими данными не происходит - это генератор сигналов специальный, он их берёт и суёт в ЦАПы, если по простому.

Решал похожую задачу - из хитрого там читалка из ддр-а - просто читать и гнать на цап нельзя из за циклов регенерации - они будут рвать поток. Поэтому пришлось изобретать хитрое ядро которое заранее вычитывало следующий блок. Ну и скорость вывода на цап подбирать что бы регенерация ддр не рвала сигнал. Если полоса сигнала на цап-е не большая (для 32 бит < 2-3ГГц), то можно обойтись и большой фифохой между ддр и джесдой.

[N_N 0]

В 16.12.2025 в 09:01, fguy сказал:

С UI на ддр4 в KU есть один неприятный сюрпрайз - если ядро ддр4 вставить в топ файл vhdl (вставить IP ддр4 с UI в BD нельзя), то сдк привидятся аж 2 микроблэйза - один обычный из BD, а другой из ддр4. Проблему решил просто - создал ядро обертку для ядра ддр4 настроенного на UI. Сам UI это по факту 3 AXI стрима.

Спасибо! Уже сделал обёртки, засовываю в BD - посмотрю что выйдет. А то текстом провода пересоединять очень напряжно, их там вагон 😕, не только от контроллера памяти, ещё от DMA и прочей лабуды, которой ещё нет.

В 16.12.2025 в 09:01, fguy сказал:

Решал похожую задачу - из хитрого там читалка из ддр-а - просто читать и гнать на цап нельзя из за циклов регенерации - они будут рвать поток. Поэтому пришлось изобретать хитрое ядро которое заранее вычитывало следующий блок. Ну и скорость вывода на цап подбирать что бы регенерация ддр не рвала сигнал. Если полоса сигнала на цап-е не большая (для 32 бит < 2-3ГГц), то можно обойтись и большой фифохой между ддр и джесдой.

Ну я утрирую. Понятно, что всё как Вы пишите, так и надо делать.

[1891ВМ12Я 0]

On 12/12/2025 at 9:10 PM, N_N said:

Сделать то это не проблема, только возник попутно вопрос - а хорошо это или плохо иметь древовидную топологию AXI, где много этих Crossbars? Надо ли стараться минимизировать их количество? Или Vivado там как то это всё оптимизирует и это всё не важно? 

Какой именно компонент используется для ветвления?