doom13 0 October 13, 2015 Posted October 13, 2015 · Report post На другом ПК (на котором и видео работает в режиме 5 GT/s) моя плата запустилась в режиме Gen 2, только надо было её прошить во флэш и передёрнуть питание ПК. Работу DMA пока не проверил, но, думаю, всё будет ОК. С моей системой какая-то беда, держит линк только в режиме 2.5 GT/s, хотя всё железо одинаковое. Quote Share this post Link to post Share on other sites More sharing options...
toshas 0 October 13, 2015 Posted October 13, 2015 · Report post Интересно узнать какую скорость удастся достигнуть. + по возможности выкладывайте проект в копилку форума. Quote Share this post Link to post Share on other sites More sharing options...
doom13 0 October 14, 2015 Posted October 14, 2015 · Report post Перебрали систему - плата запустилась на 5 GT/s. Но результат не столь значителен - всего-то удалось получить 8.5 - 8.7 Gbit/s. Тут размер бурст для DMA имеет значение: для burst 16 получаю где-то 7.2 Gbit/s, для burst 256 - 8.5 Gbit/s. В тестовых точках картина осталать прежней - очень много времени проходит между WLAST и BVALID. Quote Share this post Link to post Share on other sites More sharing options...
krux 9 October 14, 2015 Posted October 14, 2015 · Report post burst 128 попробуйте. в большинстве случаев PCIe Payload size выставляется по дефолту 128. т.е. вы одним барстом впишетесь в размер одного пакета PCIe. Quote Share this post Link to post Share on other sites More sharing options...
doom13 0 October 15, 2015 Posted October 15, 2015 · Report post burst 128 попробуйте. в большинстве случаев PCIe Payload size выставляется по дефолту 128. т.е. вы одним барстом впишетесь в размер одного пакета PCIe. Спасибо, попробовал. Но получаю те же 8.5 - 8.7 Gbit/s, что и для burst 256. Quote Share this post Link to post Share on other sites More sharing options...
doom13 0 October 15, 2015 Posted October 15, 2015 · Report post На верхнем слоте PCIe получил пропускную способность моей системы в 9.3 Gbit/s. Проверял ещё на одном ПК, дало такой же результат. Если сравнивать с резутьтатами для примера Xilinx (xapp1052), то и неплохо, но до максимума в 16 Gbit/s ещё очень далеко. Quote Share this post Link to post Share on other sites More sharing options...
doom13 0 October 16, 2015 Posted October 16, 2015 · Report post Можете в pcie-mm ядре встать анализатором на pipe интерфейс (tx и rx) ? Если можно расскажите тут подробнее, что это (pipe) и как работает? Что можно почитать по данной теме? xapp1184 достаточно будет? Quote Share this post Link to post Share on other sites More sharing options...
RobFPGA 99 October 16, 2015 Posted October 16, 2015 · Report post Приветствую! Если можно расскажите тут подробнее, что это (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. Quote Share this post Link to post Share on other sites More sharing options...
toshas 0 October 16, 2015 Posted October 16, 2015 · Report post Нет я как раз предлагал посмотреть трафик в системе (какие пакеты проходят mgt). Но в принципе не важно с какой стороны начинать разбираться. По факту надо отследить всю цепочку: MGT -1.(txdata/rxdata)- PCIE -2.(ll/s_axi) - MMcore -3.(axi)- DMA -4.(axi)- source Так можно найти, кто причина простоя, но может оказаться, что это просто следствие накладных расходов цепочки такой длины. Quote Share this post Link to post Share on other sites More sharing options...
RobFPGA 99 October 16, 2015 Posted October 16, 2015 · Report post Приветствую! Нет я как раз предлагал посмотреть трафик в системе (какие пакеты проходят 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. Quote Share this post Link to post Share on other sites More sharing options...
doom13 0 October 16, 2015 Posted October 16, 2015 · Report post ... ну или DMA например не успевает подкачивать дескрипторы. Можно попробовать разместить дескрипторы в памяти FPGA или выделить один большой непрерывный кусок физ памяти (>1MB) и все дескрипторы залинковать на него. И посмотреть изменится ли скорость или нет. Если не изменится - то тогда или пробовать на дугой мамке ... ... или потери времени на чтение/update дескрипторов велики. Все же CDMA разрабатывался для внутреннего употребления а не для PCIe. Судя по диаграммам, которые приводил выше (затык после каждого второго burst-a и длительность пропорциональна размеру burst-a), проблема не в размещении дескрипторов в Kernel space memory. Пока использую 32 дескриптора, память под них выделяется в непрерывном куске физической памяти с помощью kmalloc. Нет я как раз предлагал посмотреть трафик в системе (какие пакеты проходят mgt). Но в принципе не важно с какой стороны начинать разбираться. По факту надо отследить всю цепочку: MGT -1.(txdata/rxdata)- PCIE -2.(ll/s_axi) - MMcore -3.(axi)- DMA -4.(axi)- source Так можно найти, кто причина простоя, но может оказаться, что это просто следствие накладных расходов цепочки такой длины. Сегодня пытался проследить, кто является источником BVALID, но один из модулей зашифрован и связь теряется. Дальше куча линий с другими названиями и куда смотреть пока не разобрался. Quote Share this post Link to post Share on other sites More sharing options...
RobFPGA 99 October 16, 2015 Posted October 16, 2015 · Report post Приветствую! 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. Quote Share this post Link to post Share on other sites More sharing options...
RobFPGA 99 October 18, 2015 Posted October 18, 2015 · Report post Приветствую! Как говорится "Даренному коню в зубы .." а надо заглядывать даже в зад :) Прогнали бы на симуляции все сразу стало бы понятно. По умолчанию CDMA настроен на глубину очереди запросов адреса=4 (при этом реально выдается 4+2=6 запросов) ну а а потом CDMA шлангует пока не получит ответ/подтверждение. Поменять это безобразие в красивой формочке при конфигурировании CDMA нельзя :( Только через зад коня - ручками set_property CONFIG.C_WRITE_ADDR_PIPE_DEPTH 8 [get_bd_cells i_axi_cdma] set_property CONFIG.C_READ_ADDR_PIPE_DEPTH 8 [get_bd_cells i_axi_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 без задержек); Quote Share this post Link to post Share on other sites More sharing options...
doom13 0 October 19, 2015 Posted October 19, 2015 · Report post А что если у меня используется DMA v7.1 в режиме S2MM (CDMA был в начале)? ... также надо во всех crossbar-ах по пути следования кареты выставить постовых - значение READ_ACCEPTANCE, WRITE_ACCEPTANCE на >=8 (а то по умолчанию там стоит 2 ... Если на рисунке тот параметр, о котором шла речь, то там 8. Quote Share this post Link to post Share on other sites More sharing options...
RobFPGA 99 October 19, 2015 Posted October 19, 2015 · Report post Приветствую! А что если у меня используется DMA v7.1 в режиме S2MM (CDMA был в начале)? Думаю что тоже самое - так как CDMA это AXI DMA сконфигурированный в позе 69 через loop-back fifo. И так и есть - правда тут придется резать бедную лошадь и ковыряется в потрохах - исходниках axi_dma.vhd ... -- DataMover outstanding address request fifo depth constant DM_ADDR_PIPE_DEPTH : integer := 4; ... Если на рисунке тот параметр, о котором шла речь, то там 8. Нет это как раз и есть "бубенцы" а я имел ввиду - axi_interconect/axi_crosbar которые стоят МЕЖДУ DMA и PCIe. Вы же как то объединяете шины DMA M_AXI и M_AXI_SG для подключения к одой шине S_AXI в PCIe bidge? Успехов! Rob. Quote Share this post Link to post Share on other sites More sharing options...
