Перейти к содержанию
    

Xilinx UltraScale PCI-E, назначение двух интерфейсов

Пытаюсь освоить PCI-E на платформе Kintex UltraScale, и первое что меня удивило, это наличие двух портов: Completer и Requester. Есть пары: Requester Request (rq) + Requester Completion (rc), и Completer Request (cq) + Completer Completion (cc). Названия идеально подобраны для надежного запутывания :acute:

 

Если я планирую использовать данный интерфейс как раньше, как для Kintex-7, то какую пару мне следует выбрать? Склоняюсь к CQ+CC. Могу ли я ограничиться только лишь использование cq/cc?

Quote

The Completer Request (CQ) interface are the ports through which all received requests from the link are delivered to the user application. The Completer Completion (CC) interface are the ports through which completions generated by the user application responses to the completer requests are transmitted

В то же время есть вторая пара портов:

Quote

The Requester Request (RQ) interface consists of the ports through which the user application generates requests to remote PCIe® devices. The Requester Completion (RC) interface are the ports through which the completions received from the link in response to your requests are presented to the user application

С виду RQ+RC то же самое, но говорится о некоторых "remote pcie devices", видимо соседние устройства на шине. Какой был смысл создавать отдельный порт для этого, как это распараллелит работу - не ясно, ведь шина то одна.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Если не путаю то пара портов (Completer Request (cq) + Completer Completion (cc)) используется  для  приема запросов от внешнего Requester-а  (хоста или другого  мастера на шине) и отправки ответов на них.

А  пара  (Requester Request (rq) + Requester Completion (rc))  для  генерации (например DMA) запросов на шину и соответсвенно  приема ответов на них.

 

На  мой взгляд  вполне логично.  В старых PCIe  (например для 7 семейства) разделение  на такие каналы делалось  в пользовательском коде.

 

Удачи! Rob. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

58 minutes ago, AVR said:

видимо соседние устройства на шине

уж эта шина (PCIe) - однозначно точка-точка, т.е. других устройств на ней быть не может.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

21 minutes ago, Yuri124 said:

уж эта шина (PCIe) - однозначно точка-точка, т.е. других устройств на ней быть не может.

Точка  - точка  это сегмент  шины.   И если это разрешено в root-complex и PCIe switch,  то ничто не мешает отправить запрос с платы в одном сегменте на другую плату в другом сегменте PCIe шины.   

Удачи! Rob.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

В US/US+ совершенно другой формат подключения к IP ядру PCIe, нежели в 7 Series. В 7-й серии всё было нативно и просто - в соответствии со спекой PCIe: IP ядро реализует все уровни протокола и взаимодействует с прикладным уровнем с помощью TLP, которые соответствуют стандарту, хорошо документированы и обеспечивают однозначность интерфейса вне зависимости от целевой платформы. Все необходимые типы TLP поддержаны, разделение на запросы/завершения (request/completion) осуществляется в соответствии с типом и форматом TLP (поля Fmt и Type заголовка пакета). И итоге для пользователя это два AXI4-Stream интерфейса, используемые как туннель для TLP. Знаете спеку PCIe, этого достаточно, чтобы начать реализацию. Это значительно упрощает портирование на устройства, интерфейс которых также основан на TLP.

 

В US/US+ IP ядро использует совершенно другой формат. Там на уровне ядра внедрено разделение интерфейсов на Requester и Completer. Любой агент на шине может быть тем и другим одновременно. Если, скажем, Endpoint (EP) посылает запрос чтения, то он для этой транзакции является Requester'ом, и, соответственно, через rq интерфейс посылает MRd, а через rc получает ответ (например, от Root Complex (RC)) - данные из памяти хоста. Если наоборот RC мечет запрос на EP, то EP тут является Completer'ом: получает запрос с интерфейса cq и кидает ответ на интерфейс cc. Ну, для RC, соответственно, всё наоборот. 

 

Практический пример. Хост управляет дивайсом, но основой трафик по шине осуществляет дивайс. Т.е. хост шлёт команды на дивайс посредством записи в MMR (Memory-Mapped Registers) дивайса (отмапленные посредством BAR) - это т.н. режим PIO (Programmed IO), дивайс, анализируя записанное в регистры, производит операции чтения/записи системной памяти хоста в DMA (BMD - Bus Mastering DMA) режиме. В этом случае:

 

Режим PIO:

  • хост - Requester;
  • дивайс - Completer.

Режим BMD:

  • хост - Completer;
  • дивайс - Requester.

 

Итого получается 4 интерфейса с проприетарными заголовками (не TLP), и вариантов этих заголовков эн - для каждого интерфейса он свой. Что они этим выиграли, не понятно. Только то, что парсить TLP с целью выяснить, это запрос или завершение прилетело, не надо. Но это такая мелочь на фоне остального, что это преимущество теряется в шумах. По факту ведь эти проприетарные форматы точно так же состоят из заголовка и собственно данных пакета. И содержат они почти все те же поля TLP, но не в том порядке и не в том количестве. Попутно меняя кое-где разрядность: например, длина в TLP - это 10 бит (1024 слова), а тут оно 11 бит. Бессмысленное нововедение. То же самое касается и поля Byte Count, которое показывает, сколько байт осталось принять в транзакции. Поскольку в PCIe максимальная длина равна 4096 байт, то и в TLP (PCIe спека) это поле занимает 12 бит. Тут же они ввели 13 бит. Наверное, считают, что без старшего бита жизни нет. В реальности он не нужен, и я ловил предупреждения синтезатора о выкидывании старшего бита.

 

В общем, у меня была возможность сравнить оба подхода, потому как оба варианта я реализовывал один за другим, по свежачку. И по началу казавшаяся "логичность" подхода в US/US+ быстро разбилась о дополнительный геморрой при реализации. И работать с этим тоже лично мне оказалось неудобно - постоянно приходилось напрягать когнитивные способности, чтобы сообразить, какие буквы соответствуют из rq, rc, cq, cc. И постоянно смотреть в доку на форматы заголовков при отладке. Смастерил себе такую памятку, поставил рядом с мониторами, очень помогала:

ULZOZcc.jpg

В итоге, никакого портирования уже отработанного решения на 7 Series не получилось, пришлось по сути всё делать с нуля. Это коснулось и BFM хоста (имитация работы RC - инициирование PIO запросов, обслуживание MWR/MRd (c CplD, побитыми по RCB) со стороны EP). Двойная работа. А на хосте у них ещё используется IP ядро с шиной 512 бит, а там формат тоже отличается. В общем, куча дурацкой работы, которой не было бы, если бы сделали по спеке на TLP.

 

Думается, это не инициатива Xilinx - вряд ли они сами эти PCIe блоки изобретали, купили у кого-то, а там вот такой формат. Для PCIe Gen2 (7 серия) корка имеет нормальный TLP формат, а для Gen3 - вот такой дурацкий.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 hours ago, dxp said:

Думается, это не инициатива Xilinx - вряд ли они сами эти PCIe блоки изобретали, купили у кого-то, а там вот такой формат. Для PCIe Gen2 (7 серия) корка имеет нормальный TLP формат, а для Gen3 - вот такой дурацкий.

Ох, спасибо огромное за данный пост (или репост?) с пояснениями, я уж думал одному мне кажется это rq/rc/cq/cc бессмысленным изменением. Узнал сейчас прямо что формат там не TLP, понимание сего факта меня избегало.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Узнал сейчас прямо что формат там не TLP, понимание сего факта меня избегало.

Кстати, там помимо этого IP ядра ещё есть вариант AXI-PCIe Bridge (как-то так называется). Если вам не требуется выжимать максимальную скорость, то указанное IP ядро может подойти лучше - там просто интерфейс обычный AXI4, все эти rq/rc/cq/cc скрыты внутри.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

9 hours ago, dxp said:

Кстати, там помимо этого IP ядра ещё есть вариант AXI-PCIe Bridge (как-то так называется)

Сейчас это корка AXI DMA Bridge subsystem for PCIe,  настройками выбирается или  Bridge или XDMA вариант.   

Кстати  на чистом  AXI Bridge, с внешним  DMA контроллером на  AXI шине,  можно получить скорость передачи данных ~70-80%  от максимальной на PCIe 

 

Удачи! Rob. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Кстати  на чистом  AXI Bridge, с внешним  DMA контроллером на  AXI шине,  можно получить скорость передачи данных ~70-80%  от максимальной на PCIe 

Неплохо. А на чём он теряет?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

8 hours ago, dxp said:

Неплохо. А на чём он теряет?

Увы я особо не  изучал.
Из того что на виду на пропускную влияет в первую очередь настройки AXI шины (макс длинна burst, число outgoing транзакций,  наличие буферных FIFO) на всем пути данных.   

 

Удачи! Rob. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 7/29/2021 at 10:18 AM, dxp said:

Кстати, там помимо этого IP ядра ещё есть вариант AXI-PCIe Bridge (как-то так называется). Если вам не требуется выжимать максимальную скорость, то указанное IP ядро может подойти лучше - там просто интерфейс обычный AXI4, все эти rq/rc/cq/cc скрыты внутри.

Спасибо, надо подумать, я как то не подумал что это аналог, посчитал что это на BDF системы, но скорее всё таки я осмелюсь взяться за это rqrccqcc непосредственно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 7/29/2021 at 5:51 AM, dxp said:

Практический пример. Хост управляет дивайсом, но основой трафик по шине осуществляет дивайс. Т.е. хост шлёт команды на дивайс посредством записи в MMR (Memory-Mapped Registers) дивайса (отмапленные посредством BAR) - это т.н. режим PIO (Programmed IO), дивайс, анализируя записанное в регистры, производит операции чтения/записи системной памяти хоста в DMA (BMD - Bus Mastering DMA) режиме. В этом случае:

Сейчас вынужден вернуться к теме. Пишу кроссплатформенный модуль PCIe чтобы поддерживать Kintex 7 и UltraScale одновременно. Хотел бы уточнить еще раз. А могу ли я для bus mastering-а просто всё время использовать CQ/CC, т.е. один порт? Не будет оно блокировать мне под предлогом "а я тебе второй порт даю но ты в него не пишешь, не буду ничего слать никуда"? Для переносимости мне было бы легче использовать только 1 порт CQ+CC, только заголовки буду фиксить. Пиковые скорости не требуются. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Не вполне понял вопрос. CQ/CC есть в реализации pcie3/pcie4 (это UltraScale и UltraScale+ соответственно). В PCIe 7-й серии этих портов нет в принципе. 

 

CQ и CC - это не один порт, а два. 

 

Боюсь, что кроссплатформенность там может получиться только на уровне `ifdef <7-series-pcie> `else <us-pcie> `endif. В сторону приложения интерфейс - да, можно унифицировать. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

5 minutes ago, dxp said:

Не вполне понял вопрос. CQ/CC есть в реализации pcie3/pcie4 (это UltraScale и UltraScale+ соответственно). В PCIe 7-й серии этих портов нет в принципе. 

CQ и CC - это не один порт, а два. 

Боюсь, что кроссплатформенность там может получиться только на уровне `ifdef <7-series-pcie> `else <us-pcie> `endif. В сторону приложения интерфейс - да, можно унифицировать. 

Имел ввиду, что CQ+CC это точно так же как TX и RX порты у Kintex 7, т.е. могу я для полной функциональности использовать лишь CQ+CC и НЕ использовать RQ+RC, в том числе для DMA? Мне было бы так проще логику выстроить. Увы, Ultrascale на моем столе мне пока лишь только снится...

Кроссплатформенность я достигаю через parameter + generate if else, это удобнее чем через define - можно снаружи управлять версией.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

CQ/CC порты в дивайсе - это только для поддержания режима PIO со стороны хоста. Т.е. дивайс сможет получать короткие пакеты (записать/прочитать слово данных системной шины хоста - обычно 32-битный инт) и отвечать на них. Никакого bus mastering dma (BMD) тут не будет. BMD будет только на  портах RQ/RC. В 7-й серии Tx/Rx объединяют функции всех четырёх портов из US/US+.

 

Вам какой режим в итоге нужен? PIO или BMD?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...