Jump to content

    

Search the Community

Showing results for tags 'pcie'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Сайт и форум
    • Новости и обсуждения сайта и форума
    • Другие известные форумы и сайты по электронике
    • В помощь начинающему
    • International Forum
    • Образование в области электроники
    • Обучающие видео-материалы и обмен опытом
  • Cистемный уровень проектирования
    • Вопросы системного уровня проектирования
    • Математика и Физика
    • Операционные системы
    • Документация
    • Системы CAD/CAM/CAE/PLM
    • Разработка цифровых, аналоговых, аналого-цифровых ИС
    • Электробезопасность и ЭМС
    • Управление проектами
    • Neural networks and machine learning (NN/ML)
  • Программируемая логика ПЛИС (FPGA,CPLD, PLD)
    • Среды разработки - обсуждаем САПРы
    • Работаем с ПЛИС, области применения, выбор
    • Языки проектирования на ПЛИС (FPGA)
    • Системы на ПЛИС - System on a Programmable Chip (SoPC)
  • Цифровая обработка сигналов - ЦОС (DSP)
    • Сигнальные процессоры и их программирование - DSP
    • Алгоритмы ЦОС (DSP)
  • Микроконтроллеры (MCs)
    • Cредства разработки для МК
    • ARM
    • AVR
    • MSP430
    • Все остальные микроконтроллеры
    • Отладочные платы
  • Печатные платы (PCB)
    • Разрабатываем ПП в САПР - PCB development
    • Работаем с трассировкой
    • Изготовление ПП - PCB manufacturing
  • Сборка РЭУ
  • Аналоговая и цифровая техника, прикладная электроника
  • Силовая Электроника - Power Electronics
  • Интерфейсы
  • Поставщики компонентов для электроники
  • Майнеры криптовалют и их разработка, BitCoin, LightCoin, Dash, Zcash, Эфир
  • Дополнительные разделы - Additional sections

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Сайт


ICQ


Yahoo


Jabber


Skype


Город


Код проверки


skype


Facebook


Vkontakte


LinkedIn


Twitter


G+


Одноклассники

Found 9 results

  1. Собственно задача - с минимальными потерями времени и усилий работать с хоста через PCI-E с ускорителем в ПЛИС. Насколько я понял самый простой способ - использование ядра XDMA (обёртка над ядром PCI-E) [1], готовых драйверов xdma.ko [2] и шаблонов приложений которые идут в комплекте [3] Но после вдумчивого изучения pg195 и запуска на плате тестового примера остались вопросы, хотя они скорее системного плана, но связаны именно со спецификой ядра XDMA. Что надо от ускорителя (для определенности - пусть будет крипто-ускоритель): 1) "стримить" с хоста данные на обработку, притом чтобы ускоритель мог сообщать, что достаточно, пока больше не надо присылать данные (т.е. некий flow control на отправку) 2) уведомлять хост о том, что данные обработаны и можно забирать, и соответственно отдавать "стрим" в хост. Почему стрим в кавычках: по сути это не непрерывный стрим, а блоки по 4К (притом с заголовками, чтобы на приёмной стороне (хосте) можно было сматчить контекст - какому выходному блоку какой входной соответствовал), но по природе обработки ускоритель это как PIPE: с одной стороны вышло, с другой вышло и есть некая "глубина" внутри - чтобы начал выдавать первые данные надо несколько десятков блоков в него "застримить". Т.о. в терминах xdma для этой задачи AXI Stream подходит очень хорошо, но вот на тестовом проекте заметил нестабильную работу AXI Stream (пропадание данных) в связи с чем рассматриваю и AXI MM как альтерантиву. Но что бы написать "правильное" и надёжно работающее хостовое приложение хотелось бы понимать несколько вещей (далее список вопросов): ##### BAR ##### pg195, таблица 3, соответствующа вкладка в конфигураторе XDMA * DMA - это собственно работа с самим движком * Bypass DMA - думал что это прямой доступ к пространству памяти карточки в обход движка ДМА, но похоже это не так, это ЕЩЕ ОДНО выделенное адресное пространство (доп.канал) никак не связанное ни с движком ДМА ни с памятью в которую пишет движок ДМА. * AXI Lite Master - видимо от Bypass DMA отличается только тем, что это Lite 1.1 Смущает то, что для BAR DMA в режиме AXI MM в конфиге вивадо никак не задаётся размер BAR - это как?.. где/чем определяется размеры адресного пространства с которым работает карточка? 1.2 Далее в разделе про прерывания вскользь упомянуто, что BAR может быть _address space_ а может быть и _register space_. Надо ли держать это в уме или при использовании готового драйвера просто работать с /dev/xdma0_xxx и не париться? 1.3 Какие реальные кейсы могут быть для использования Bypass DMA ? ##### IRQ & user app ##### У самого IP-ядра есть внешние ножки прерывания, но как их использовать pg195 ответа не даёт, ограничиваясь тестовым примером проекта, в котором прерывания взводятся записью из хостовой программы в регистр в пространстве AXI Lite Master. Но как это обработать из хостовой программы совершенно неясно: 2.2 Вот мы открыли /dev/xdma0_h2c и льём туда данные, как считать прерывание "BUSY", что дескать лить хорош уже (и дальше ждать прерывания "FREE") - как это на стороне пользователя обрабатывать? 2.2 При приёме мы открываем /dev/xdma0_c2h и ждём прерывания "READY" указывающее на готовность данных в /dev/xdma0_c2h - как это на стороне пользователя обрабатывать? 2.3 Чем "правильнее" пользоваться на стороне карточки - ножками usr_irq_req и usr_irq_ack, или же механизмом MSI (msi_enable, msi_vector_width)? 2.4 В AR654444 еще описан способ загрузки драйвера в режиме поллинга (работает только в направлении c2h) - стоит ли использовать его вместо прерывания для упощения логики приложения? ##### AXI ST ##### Самое интересное: управление потоками, нарезка на "пакеты" DMA H2C Stream -------------- For host-to-card transfers, data is read from the host at the source address, but the destination address in the descriptor is unused. Packets can span multiple descriptors. The termination of a packet is indicated by the EOP control bit. A descriptor with an EOP bit asserts tlast on the AXI4-Stream user interface on the last beat of data. - т.е. на стороне хоста за формирование для AXI4-Stream сигнала tlast, который фактически нарезает пакеты как мне надо, отвечает отвечает механизм, выставляющий бит EOP (в TLP???) 3.1 достаточно ли для user app указать size=4K, для формирования EOP в xdma.ko? 3.2 см. пп.1.1 если мы не задали размер BAR для DMA, то кто будет заботиться о буферах в движке DMA на карточке и в пользовательском РТЛ коде? Буферы в движке DMA на карточке вообще черный ящик: вот отправим мы пакет с size=1М - куда его сохраняет движок DMA? - не налету же он его в пользовательскую логику передаёт??? 3.3 по размерам нашёл такое упоминание в PG195, эти значения как-то завязаны на размер внутренних буферов движка ДМА??: DMA C2H Stream -------------- For card-to-host transfers, the data is received from the AXI4-Stream interface and written to the destination address. Packets can span multiple descriptors. The C2H channel accepts data when it is enabled, and has valid descriptors. As data is received, it fills descriptors in order. When a descriptor is filled completely or closed due to an end of packet on the interface, the C2H channel writes back information to the writeback address on the host with pre-defined WB Magic value 16'h52b4 (Table 10: C2H Stream Writeback Fields), and updated EOP and Length as appropriate. - тут вроде бы тоже всё прозрачно - нарезаем пакаты для отправки сигналом tlast в AXI4-Stream, который по идее должен устанавливать в дескрипторе поле EOP 3.4 Удаляет ли при приёме дескриптор с WB Magic драйвер xdma.ko или же его должно удалять пользовательское приложение? 3.5 не очень понятна строка "For valid data cycles on the C2H AXI4-Stream interface, all data associated with a given packet must be contiguous" - означает ли это, что до взведения tlast надо держать tvalid и лить данные без пропуска клоков (иначе движок ДМА "отрежет" и отправит пакет на хост по таймауту)? ##### AXI MM ##### 4.1 опять см. пп.1.1 - как задаётся размер пространства для AXI MM? В интерфейсе конфигурирования нет такой настройки. ##### источники ##### [1] https://www.xilinx.com/support/documentation/ip_documentation/xdma/v4_1/pg195-pcie-dma.pdf [2] https://github.com/Xilinx/dma_ip_drivers [3] https://github.com/Xilinx/dma_ip_drivers/tree/master/XDMA/linux-kernel/tools
  2. Всем привет! Artix7 Vivado 2019.1 Debian10 Собрал систему Axi Memory Mapped to Pci Express, CDMA, DDR3. Задача в том что бы посылать данные через PCIe в DDR с помощью DMA. В данный момент с ПК данные записываются в DDR ПЛИСа со скоростью 500Мб/с, что для заданных целей проекта мало. В ip PCIe у меня выделено 3 бара: DDR,BRAM, регистры CDMA. Всё прекрасно пишется и читается, но как я сказал выше, медленно. Так же в этой коре выделен один AXI BAR с адресом 0x40000000, который транслируется в адресное пространство CDMA как BAR0 PCIe'са и имеет адрес 0x60000000. Написал простенький дравер на линикс под данные цели, где заполняю регистры DMA. Адрес назначения = 0x80000000 (это адрес ddr в адресном пространстве cdma) и адрес источника который возвращает драйвер как выделенную память под dma, затем устанавливаю количество байт, что активирует трансфер из сорса в адрес назначение и в идеи данные из буфера выделенного драйвером в ПК должны появиться в ddr ПЛИС, но их там нет. Если сорс адрес ставить bram, то по той же схеме через драйвер, данные передаются из brem в ddr. Не могу понять что упускаю... pdf блок диаграммы, настройки и драйвей под линукс прикрепил. Можно попросить посмотреть файлы? Может кто нибудь подскажет что я не правильно делаю. PS не нашел ответов в и в Xilinx Answer 65062 AXI Memory Mapped for PCI Express Address Mapping design_1.pdf test_pci.c настройки и адреса.pdf
  3. Здравствуйте, уважаемые форумчане! Я в PCI-e новичок. Встала передо мной такая задача: нужно преобразовать поток данных от двух PCI Express Gen3 устройств (каждое х8) в один поток данных Gen4 также по x8 линиям. То есть соединить два устройства со скоростями Gen3 в одно со скоростью Gen4. Можно ли это сделать в принципе без кастомных FPGA-узлов? Может есть спец микросхемы?
  4. Всем привет! Возникла проблема в конфигурации FPGA в режиме PCIE3.0 Tandem у отладочной платы KCU105. В проекте есть светодиод (led 0 на плате), который при второй стадии загрузки (по PCIE3.0) должен включатся. Порядок действий: Собираю проект design example. Констрейны для bitstream: После сборки генерирую MCS командой: Прошиваю конфигурационную память скриптом который есть в архиве program_spi.tcl Выключаю хост. Потом включаю. После загрузки вижу девайс: Читаю регисры с помощью mcap версия bitstream совпадает с ожидаемой. Прошиваю второй стадией: Поле прошивки ядро выдает сообщеие: После этого светодиод не горит, а mcap говорит: А если прошить FPGA по JTAG первой стадией, затем сделать reboot и прошить mcap воторой стадией, то светодиод горит и сообщения в ядре по irq нет. Данное IRQ принадлежит: Память конфигурационная память прошивается, через JTAG бластер по разъему J3. Версии: Vivado v2019.1 (64-bit) Хост в котором карточка Linux 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux Утилиты MCAP взята отсюда https://www.xilinx.com/support/answers/64761.html Ревизия KCU105 C Версия pci-utils pciutils-3.3.1 пробовал и с 3.6.3 одинаковый результат. В чем может быть проблема? pcie3_ultrascale_0_ex.zip
  5. Вопрос не в том, можно ли так по правилам (читай - стандартам), а в том - можно ли от них и насколько отходить. Итак: дифференциальный RefClk частотой 100МГц надо заводить на каждый PCI-E target, основная цель, я так понимаю - чтобы у мультигигабитных трансиверов был исходный клок с одним и тем же дрейфом. Вопрос: а можно ли не заводить, а генерить локально? в сети разные мнения, от Note that the pcie bus ref clock needs to be common between all devices communicating on the pcie bus. До https://www.xilinx.com/support/answers/18329.html с техникой Asynchronous Clocking Также есть такая вот картинка: которая вроде бы говорит, что такое вроде как приемлемо, но хотелось бы ответа практиков. Зачем это всё? Есть девборда с Xilinx US/US+ c FMC но без PCI-E слота, сейчас появилась необходимость работать с PCI-E самая простая и материально незатратная идея реализовать это: изготовить райзер из FMC в PCI-E (через тот же USB3.0 кабель, которй используется китайцами повсеместно для выноса с материнки PCI-E 1х ). Но вот незадача - на FMC разведены мультигигабитные трансиверы, но задающий клок для них распаян локально на плате (номинал может программироваться во внешней фапч), резать дорожки, куда-то там подпаиваться - такой кейс совсем исключён. Поэтому для принятия решения о райзере хотелось бы заручиться уверенностью что заработает хотя бы в лабораторных условиях (в продакшене это использоваться не будет). (лабораторных условиях == температура 25С, что должно снизить разбос задающих частот на разных концах MGT)/ PCIe-Clock-Source-Selection.pdf
  6. Всем привет! Прошу помощи. Кто-нибудь знает, как правильно пользоваться сигналами fc_* из ядра PCIe? Вообще суть проблемы такая. Имеется плата с Spartan 6 45T. Firmware предоставляет регистры для записи-чтения по инициативе процессора (как memory), через них задаётся, что делать. Потом firmware делает запросы к памяти (DMA). Я реализовал flow control по четвёртому методу DATA_FC из UG672. Значения Total_CplH и Total_CplD брал, как рекомендовано, из таблицы E-1 (для моего случая 32 и 256 соответственно), хотя там дальше говорится: In the case where infinite credits have been advertised to the Link Partner for a specific Credit pool, such as Completion Credits for Endpoints, the user application should use this value along with the methods described in Appendix E, Managing Receive-Buffer Space for Inbound Completions to avoid completion buffer overflow. И до поры, до времени всё работало замечательно, но вот я нарвался на то, что передача данных затыкается при работе с процессорным модулем ComExpress - запросы из FPGA MEMORY_READ ушли, а ответов на них не пришло. Подозреваю, что у этого модуля более суровые ограничения на число запросов в очереди. Решил посмотреть на то, какие значения выставляются на fc_ph, fc_pd, fc_nph, fc_npd, fc_cplh и fc_cpld для разных значений fc_sel в разные моменты времени. Должен сообщить, что значения эти выглядят странными и непонятными, причём, я не нашёл какого-то внятного user guide, чтобы там объяснялось, как этими сигналами правильно пользоваться для целей flow control. Например, для fc_sel=000 (Receive Credits Available Space) значения такие: fc_ph = 32, fc_pd = 211, fc_nph = 8, fc_npd = 8, fc_cplh = 40, fc_cpld = 211 (Крайне смущают очень маленькие значения для fc_nph и fc_npd.) для fc_sel=100 (Transmit Credits Available Space) значения такие: fc_ph = 12, fc_pd = 80, fc_nph = 12, fc_npd = 1, fc_cplh = 0x7F, fc_cpld = 0x7FF (в соответствии с таблицей 5-17 из UG672 значения 0x7F и 0x7FF обозначают Infinite credits available). Я правильно понимаю, что мне надо взять fc_nph = 8, fc_npd = 8 вместо 32 и 256 для Total_CplH и Total_CplD?
  7. Подскажите, пожалуйста, видел ли кто-либо где-либо реализацию 128b/130b (8GT/s, Gen3+) PCIe PHY? Решил попробовать написать свою PCI корку для работы с хостом, т.к. не устраивает скорость работы хардварного альтеровского IP.
  8. Форумчане, доброй ночи. Подскажите, может кто сталкивался. Бьюсь третий день. 1) Развернул корку на Stratix V, PCIE avalon 256bit + DMA 2) пытаюсь драйвер сделать, ничего не идет. 3) Что выяснил. При попытке записать что то в BAR0, BAR4, вешается компьютер. Ровно после тридцать девятой попытки записи четырех байт происходит зависание. При это сразу считываю, что там записалось, а ничего ничего не записалось. 4) Jungo Wizard пишет что BAR0, BAR locked. В Jungo так же пытаюсь записать и сразу прочитать. Не записывает значения. Уже начинаю склоняться, что то с альтерой или коркой. Может кто сталкивался с такой проблемой.
  9. Смотрю сейчас на кабели PCIe (Samtec в частности) и возник дурной вопрос: я правильно понимаю, что для случая когда с обеих сторон Edge Connector, все сигналы как переворачиваются? То есть то что было на стороне A одного разъема, оказывается на B на другом и наоборот? Никогда раньше дела с такими не имел, наверное это подразумевается, но явно не написано https://www.samtec.com/products/pciec http://suddendocs.samtec.com/catalog_english/pciec.pdf