На другом ПК (на котором и видео работает в режиме 5 GT/s) моя плата запустилась в режиме Gen 2, только надо было её прошить во флэш и передёрнуть питание ПК. Работу DMA пока не проверил, но, думаю, всё будет ОК. С моей системой какая-то беда, держит линк только в режиме 2.5 GT/s, хотя всё железо одинаковое.

Интересно узнать какую скорость удастся достигнуть.
+ по возможности выкладывайте проект в копилку форума.

Перебрали систему - плата запустилась на 5 GT/s. Но результат не столь значителен - всего-то удалось получить 8.5 - 8.7 Gbit/s. Тут размер бурст для DMA имеет значение: для burst 16 получаю где-то 7.2 Gbit/s, для burst 256 - 8.5 Gbit/s.
В тестовых точках картина осталать прежней - очень много времени проходит между WLAST и BVALID.

burst 128 попробуйте.
в большинстве случаев PCIe Payload size выставляется по дефолту 128.
т.е. вы одним барстом впишетесь в размер одного пакета PCIe.

Спасибо, попробовал. Но получаю те же 8.5 - 8.7 Gbit/s, что и для burst 256.

На верхнем слоте PCIe получил пропускную способность моей системы в 9.3 Gbit/s. Проверял ещё на одном ПК, дало такой же результат.
Если сравнивать с резутьтатами для примера Xilinx (xapp1052), то и неплохо, но до максимума в 16 Gbit/s ещё очень далеко.

Если можно расскажите тут подробнее, что это (pipe) и как работает? Что можно почитать по данной теме?
xapp1184 достаточно будет?

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


Нее - в PIPE лезть не нужно - это интерфейс к MGT - toshas наверное имел ввиду шины s_axis_rq_* s_axis_rc_* на самой pcie корке которая внутри bridge
Через эти шины TLP идут request/completion от bridge логики к pcie корке. Цепляете туда ChipScope - а еще лучше логер который будет Вам скидывать TLP header-ы и смотрите что куда тормозит. Конечно это сначало проще было бы на симе сделать.

Тут либо сам bridge не заточен на макс thruput, ну или DMA например не успевает подкачивать дескрипторы.
Можно попробовать разместить дескрипторы в памяти FPGA или выделить один большой непрерывный кусок физ памяти (>1MB) и все дескрипторы залинковать на него. И посмотреть изменится ли скорость или нет.
Если не изменится - то тогда или пробовать на дугой мамке, или скорее всего bridge не заточен на макс thruput, ну или универсальная причина №3 - ХЗ .

Успехов! Rob.

Нет я как раз предлагал посмотреть трафик в системе (какие пакеты проходят mgt).
Но в принципе не важно с какой стороны начинать разбираться.
По факту надо отследить всю цепочку:
MGT -1.(txdata/rxdata)- PCIE -2.(ll/s_axi) - MMcore -3.(axi)- DMA -4.(axi)- source
Так можно найти, кто причина простоя, но может оказаться, что это просто следствие накладных расходов цепочки такой длины.

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


Ой - разбирается на уровне PIPE это труба дело . DLP layer, K-коды, AK-и NAK-и постоянно туда сюда снуют. ужас!
Проще сначала на TLP layer посмотреть. Так как операция WRITE на PCIE не требует completion то тут или в bridge для PCIe настройки буферов зажаты или потери времени на чтение/update дескрипторов велики. Все же CDMA разрабатывался для внутреннего употребления а не для PCIe.

Я вот свою железку симулирую - так latency на чтение дескриптора из памяти ~500 нс (x8 gen2) и это при PIPE симуляции и без задержек на стороне модели RC.

Успехов! Rob.

Судя по диаграммам, которые приводил выше (затык после каждого второго burst-a и длительность пропорциональна размеру burst-a), проблема не в размещении дескрипторов в Kernel space memory. Пока использую 32 дескриптора, память под них выделяется в непрерывном куске физической памяти с помощью kmalloc.


Сегодня пытался проследить, кто является источником BVALID, но один из модулей зашифрован и связь теряется. Дальше куча линий с другими названиями и куда смотреть пока не разобрался.

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

BVALID формирует axi_bridge когда видит что очередной AXI пакет полностью и окончательно отправился к праотцам (передан на RC).
Повторюсь - так как для MEM_WRITE на PCIe не требуется completion со сторонв RC то это событие для bridge (окончание отправки пакета)
скорее всего происходит в момент записи последней порции payloda в виде TLP пакета по шине s_axis_rq_* в PCIe корку. При этом пакет TLP сначала попадает во внутренний буфер PCIe корки а затем уж передается в RC, при условии что RC готов принят этих беженцев (есть место в приемных буферах)
Если на стороне RC нет свободных буферов для приема и внутренний дворик корки тоже заполнен то корка снимает s_axis_rq_ready.
Так что подключившись s_axis_rq_* можно посмотреть - есть ли там паузы или это bridge тупит.

Успехов! Rob.

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

Как говорится "Даренному коню в зубы .." а надо заглядывать даже в зад Прогнали бы на симуляции все сразу стало бы понятно.

По умолчанию CDMA настроен на глубину очереди запросов адреса=4 (при этом реально выдается 4+2=6 запросов) ну а а потом CDMA шлангует пока не получит ответ/подтверждение. Поменять это безобразие в красивой формочке при конфигурировании CDMA нельзя Только через зад коня - ручками
Но один конь карету не помчит - также надо во всех crossbar-ах по пути следования кареты выставить постовых - значение READ_ACCEPTANCE, WRITE_ACCEPTANCE на >=8 (а то по умолчанию там стоит 2 - даже не лошадь - дохлая кляча получается ). Ну и бубенцы на хомут - значения больше 8 ставить смысла нет так как bridge больше 8 запросов в очередь не принимает, а вроде бы соответствующие параметры c_s_axi_num_read/c_s_axi_num_write расположенны слишком глубоко в зад.. read_only

Успехов! Rob.

P.S. Ни одно животное не пострадало. Все эксперименты проводились на виртуальной лошади с "заездами" на идеальной трассе (PIPE sim. , BFM RC без задержек);

А что если у меня используется DMA v7.1 в режиме S2MM (CDMA был в начале)?


Если на рисунке тот параметр, о котором шла речь, то там 8.

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


Думаю что тоже самое - так как CDMA это AXI DMA сконфигурированный в позе 69 через loop-back fifo.
И так и есть - правда тут придется резать бедную лошадь и ковыряется в потрохах - исходниках



Нет это как раз и есть "бубенцы" а я имел ввиду - axi_interconect/axi_crosbar которые стоят МЕЖДУ DMA и PCIe. Вы же как то объединяете шины DMA M_AXI и M_AXI_SG для подключения к одой шине S_AXI в PCIe bidge?

Успехов! Rob.