Что такое значение регистров BAR и зачем его читать? https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%...D0%B2%D0%BE_PCI Base Address Register
От хоста просто приходит некий пакет. Некоторые (если не все) IP ядра дают сигнал типа bar hit - показывают, в какой именно BAR (если вообще попал) и его диапазон попал адрес из пакета. Но вообще-то, какой смысла устройству знать значение этого регистра? Этот адрес имеет значение для хоста, а не устройства. Пришел пакет например чтения, и у него есть смещение - значит мы понимаем что хотел хост.
Я может уже забывать начал, но мне никогда не надо было знать значение BAR непосредственно...

А если ПЛИС инициирует запись в хост, как узнать какой адрес вставлять в заголовок TLP посылки?

Для этого в системе необходим драйвер (модуль ядра), который выделяет кусок памяти, передаёт адреса данной памяти в FPGA (настраивает DMA).

Мы ведь на тему BAR? Для этого придумали MSI-прерывания. Драйвер просыпается от прерывания и хост читает некий регистр, причем тогда, когда ему удобно. Лучше пусть хост будет мастером всех этих процессов. А прочитав статусный регистр устройства ему будет ясно, что нужно делать дальше.

Приветствую!
В симуляции с PIPE в основном сложности с подключением веревок интерфейсов. Ну и некоторые нюансы с настройкой параметров для PCIe корки для работы с симуляцией PIPE (чтоб не ждать долго инициализации линка). К тому же у Xilinx немного разные наборы сигналов для разных версий PCIe. Ну и некоторые проблемы возникают при генерации корки. Если точнее то раньше можно было сгенерировать корку как обычно c MGT а потом уже при симе параметром выбирать интерфейс PIPE/MGT режим. А сейчас так не получается (на оптимизировали блин) либо генериш и симиш ее с PIPE, либо с MGT.
Если использовать для симуляции root-complex BFM такую же корку от Xilinx то особых проблем для коннекта с PIPE нет.

Например у меня такой вот шаблон для теста PCIe установленных на BD диаграммах.

Ну а если PCIe BFM сторонний то надо будет мудрить с адаптером PIPE.

Удачи! Rob.

Спасибо за ответ, прошу прощения за паузу, не был готов задавать вопросы.



Вот тут начинаются непонятности. Изучение темы PIPE привело к следующему: PIPE - есть промежуточный внутренний интерфейс (придуманный Интелом) между MAC и физическим уровнем, некий аналог MII/GMII/SGMII и прочих для изернета. И хотя он называется PIPE - Physical Interface for PCI Express, он же используется и для USB, DisplayPort и других высокоскоростных сериальных интерфейсов (понятно, что в каждом случае со своими особенностями).

Т.е. это не какой-то виртуальный отладочный интерфейс, но вполне реальный, боевой. Он может быть как внешним, когда, например, к ПЛИС цепляется внешняя микросхема PCIe PHY (видел дизайн на Spartan3 + NXP PCIe PHY), так и внутренним - удобно передавать между вендорами и на уровне IP ядер в ASIC'остроении.

Понятно, что если решение монолитное, т.е. одна микросхема, в которой всё, то этот PIPE, если он там есть, является внутренним интерфейсом и наружу не высовывается за ненадобностью. Но в ряде случаев его можно использовать для отладки. Например, логичным выглядит при моделировании в симуляторе исключить из оного MGT блоки, которые, во-первых, сложны и эта сложность никак не помогает при функциональном моделировании, а только мешает, во-вторых, работают на высоких частотах, что будет сильно грузить симулятор совершенно без профита. Т.е. соединить тестируемые блоки напрямую через их PIPE интерфейсы, минуя MGT.

Вроде так, поправьте, если неверно понял.

Так вот, учитывая вышесказанное, просится задействовать PIPE для моделирования. В настройках PCIe IP ядра есть следующая опция:



о чём в доке (PG054) коротко и просто сказано:

• None: No PIPE mode simulation is available. This is the default value.

• Enable Pipe Simulation: When selected, this option generates the core that can be simulated with PIPE interfaces connected. This option is enabled for both Endpoint and Root Port configurations only when the Shared Logic (clocking) in example design option is selected (see Shared Logic, page 234).

• Enable External PIPE Interface: When selected, this option enables an external third-party bus functional model (BFM) to connect to the PIPE interface of the Integrated Block for PCIe. This feature has been tested only with BFM from Avery Design Systems (XAPP1184 [Ref 21]). For more information, see PIPE Mode Simulations, page 264.

Самое непонятное со вторым пунктом. Вроде сказано, что в этом случае рожается "core that can be simulated with PIPE interfaces connected". Но при этом никаких изменений в портах ядра по сравнению с вариантом None не видно. Где там PIPE интерфейс, которые можно законнектить с ответной частью? Что понимается под PIPE simulation?

Такой интерфейс появляется в третьем случае, про который прямо сказано, что это для коннекта с "external third-party bus functional model". Изучая ваш шаблон, пришёл к выводу, что вы-то как раз этот вариант и используете. Или нет? Судя по сигналам, таки да. Но тогда не понятно, откуда взялась BFM от Xilinx для этого варианта, если они сами отсылают к сторонним. Кстати, апноту, а которой они отсылают (XAPP1184), изучил, там всё более-менее понятно, только вот самой модели тоже нет и ссылка к ней [очевидно, давно] протухла. Да и не больно-то и хотелось.

Я пробовал все три варианта. Во всех случаях соединение идёт через GT, время прогона одинаковое. Т.ч. по факту оно ни на что не влияет. Что-то сделал не так?

Правильно ли я понял про



что тут речь идёт именно о третьем варианте (Enable External PIPE Interface), где нужно потроха pipe_tx/rx_n_sigs и common_commands_in/out раскидать на правильные сигналы и подключить их к ответной стороне?


А можно поподробнее: что тут конкретно делается?

Ну, и про симулятор. Каким вы пользуетесь? Вообще и в частности для моделирования PCIe. Компиляция библиотеки для PCIe хочет зашифрованный файл из secureip, и это вызывает сложности с использованием сторонних симуляторов совместно с современной версией Vivado (текущая хочет Model/Questasim 10.6с, которого не найти).

И последний вопрос: есть ли какие-либо проблемы с синтезатором? Ну, например, на одних версиях работает, на других нет? Периодически вижу, как народ жалуется, что вот выходит новая версия вивады/квартуса, и проект перестаёт собираться и/или работать. Вы на какой версии успешно это синтезировали?

Приветствую!
Да так и есть - PIPE это некая спецификация для коннекта между Logic layer и Phy Layer.

Уточните версию софта - судя по картинке это гдето 2016.*
Это как раз та "сложность" подключения веревок" Как я понял все это безобразие - так как PIPE интерфейс нужен
был только для симуляции то Xilinx изначально не рассчитывал вытягивать веревки наружу корки. А цеплял симулятор через жо.. механизм force напрямую через иерархию. При этом сама корка была "правильной" с точки зрения RTL дизайна - все top параметры корректно меняли структуру корки - то есть можно было сгенрить корку - воткнуть ее в RTL и меняя параметр PIPE_SIMULATION получать симуляцию с PIPE или GTE - красота! Потом добавили опцию генерации внешних PIPE веревок для унификации интерфейсов. Потом судя по всему концепция поменялась и начиная с какой то версии (и какой то матери) параметр PIPE_SIMULATION на топе корки ни на что не влияет. Так как часть структуры корки меняется при генерации корки скриптом напрямую в RTL!. Поэтому сейчас - блин - приходится генерить отдельно для симуляции - отдельно для P&R И получается фигня - то есть веревки интерфеса PIPE - то их нет. И что? каждый раз менять TB?

И да и нет. Так как изначально я цеплялся к PIPE вариантом force - так как PCIe у меня не всегда близко к топу дизайна то мне лень страдать вытаскиванием PIPE интереса наружу. Поэтому такой вот шаблон - куда бы нелегкая не занесла PCIe я поменяв путь к ней в `define подключусь к висящим там PIPE веревкам.
Эта BFM взялась из отвращения "уважения" к тому примеру который дает Xilinx Сейчас внутри это обычная AXI-PCie bridge (x8 gen3) корка в режиме root-complex к которой прикручен писаный на sv BFM имитирующий работу CPU. С основными прибамбасами по инициализации PCIe, BAR, чтению/записи регистров, системной памяти, обработке прерываний, XDMA, и.т.д. Была мысль прикрутить через DPI прослойку для отладки софта и драйверов. Я как то пытался прикручивать к PIPE внешную BFM DrivExpress - и даже заработала - но функционал оказался бякой.

А это как раз "некоторые нюансы" с настройкой параметров для PCIe - То что корка была сгенерирована с PIPE интерфейсом это не значить что она готова с ним работать Надо подправить некие внутренние параметры модулей чтобы PIPE заработал как раз это и делается через defparam...
Это больше 2 чем 3 вариант. Для 3 нужно вытягать шины наружу в TB и подключать их как обычные порты.
Force позволяет подключится к цепи внутри дизайна вместо имеющегося источника. То есть когда сгенерировал на BD корку с PIPE интересом но никуда его не подключил то Vivado по умолчанию на неподключенные входы цепляет 0. Force отцепляет этот 0 и подключает ко входам выходы PIPE из root-complex BFM.
Пользую QuestaSim 10.4e. Сейчас смотрю что и как с 18.2 Вроде компилирует - но есть всего 1 ошибка при компиляции как раз в XDMA. Как мне кажется пока не связанная с криптованием.
Для Xilinx я успешно синтезировал начиная с версии ISE 3.1 вроде C PCIe в Vivadо работаю с 14 версии. В железе вроде все работает. Как раз синтезатор в Vivado относительно неплох. Хоть раньше я в основном пользовался Synplify (да и сейчас периодически смотрю в нем что и как получается) но особой необходимости заменить им вивдовский пока не было.
Vivado пока еще сыровато и многое меняется как в интерфейсе так и структуре. И в любой версии есть свои глюки. Поэтому хочется стабильности - миришся с тем что есть, манять новые плюшки - тянешь проекты вперед. Если лень (и можеш себе позволить ) - держишь зоопарк версий. Сейчас у меня в основном работа на 17.4 и немного на 15.3 и 17.1.

Успехов! Rob.

Самая что ни на есть 2018.2. Это для 7-Series FPGA, возможно для более толстых семейств вид уже другой.


Я правильно понял, что раньше (совсем раньше) было две опции: None и Enable PIPE Simulation, и при генерировании example project сам Xilinx уже выполнял подключение RP и EP обоими способами - и через GT, и через PIPE (путём force), только при None параметр PIPE_SIMULATION был FALSE, а при Enable PIPE Simulation этот параметр становился TRUE, что автоматически переключало поток между RP и EP по тому или иному пути, а для юзера всё было вообще просто и шоколадно?

И уже несколько позже добавили третью опцию Enable External PIPE Interface, которая выводила сигналы PIPE наружу модуля - не очень понятно зачем, если так всё было просто и удобно. А потом вообще убрали внутреннее подсоединение PIPE через force, и теперь приходится самому вручную геморроиться, генерируя два несовместимых варианта корки - при None получатся годная для синтеза, но бесполезная для симулятора (т.к. внутри нет доступных PIPE сигналов), а при Enable PIPE Simulation и Enable External PIPE Interface получается негодная для синтеза (из-за лишних несинтезируемых сигналов), но подходящая для симулятора. Так?

Или вторая опция (Enable PIPE Simulation) вообще пустая (меняет только никому не нужный параметр PIPE_SIMULATION), а реально работают только первая (для синтеза) и третья (для симулятора). А вторая опция по сути даёт то же что и первая. Так?


Вы сами её написали или перепилили тот вариант, что идёт вместе c example project? Я посмотрел, там очень немало кода, с нуля такое написать - надо иметь очень много свободного времени и неслабое желание.

И что вызвало "уважение" к примеру от Xilinx? Что-то не работало или просто сделано всё так, что неюзабельно?


Посмотрел в вашем шаблоне, там только два параметра настраиваются:



Это просто для примера или этого достаточно? Так понял, что первый параметр рулит, выдавать ли PIPE интерфейс наружу, а второй... похоже, что управляет включением/выключением какой-то инициализационной фазы. У моей корки такого параметра нет, но есть такой:



возможно, это аналог - включает/выключает быструю тренировку линка. Оно?


Резюмируя, какую опцию вы используете для синтеза (None или Enable PIPE Simulation) и для симулятора (Enable PIPE Simulation или Enable External PIPE Interface)?


Да, подтверждаю, 10.4e решает проблему (ранее была 10.4a). Вивада выдаёт предупреждение, что версия не та, но дальше всё работает - это означает, что в этой версии есть подходящий ключ для дешифрования.

Попутно выяснилась подлая штука: оказывается, что если компилировать либы для одного семейства, то компилирует он не все, а только часть, при этом модель, используемая в выбранной FPGA, тем не менее ссылается на файлы, которые не попали в компиляцию. Выход: при компиляции невзирая указывать -family all. Подробнее тут.

Ну, и сделал прогон тестового проекта на вивдовском симуляторе и на квесте. Результат:

Vivado: 8:46
Questa: 1:12

Соотношение 1:7.3. Вот так вот. Ну, и вообще, вивадовский сим совсем какой-то неповоротливый - он и компиляет, и элаборацию делает в примерно такое же время раз дольше, чем квеста. Такое впечатление, что он целиком (и движок тоже) на жабе написан. Или на тикле.

P.S. Кстати, не оценивали, какая разница в скорости прогона при коннекте через GT и через PIPE? Сколько там - проценты или разы? Стоит ли морочиться с PIPE в реальности? И если даже при подключении RP и EP через PIPE путём force поток идёт мимо GT, сами-то трансиверы никуда не делись - они же как объекты остались и работают на своей скорости (гигагерцы), а значит должны сожрать производительность симулятора. Или не так - т.е. если у них отобрать поток данных (через force), то они просто болтаются там в статике и никому не мешают?

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

Да так и есть (вернее было).

Да - Если включаеш любую опцию Enable PIPE Simulation скрипт при генерации корки вырезает кусок RTL для синтеза. И наоборот.
Может это и поправили в 18 версии но пока некогда ковырятся проверять.
Нет - 2 и 3 это одно и тоже - только 3 еще и внешний порт создает чтобы с force не мучатся.

Сам. В основном время ушло на разбор что нужно, что и как делаетя в примерах работы с PCIe Xilinx (и Алтера тоже). Ну и несколько вариантов разных.
Код у Xilinx старый - видно что писан еще во времена голого verilog отсюда такая громоздкая структура.
А хотелось чтобы для user было типа такого -


Этого достаточно для работы с AXI-PCIe bridge и с PCie XDMA, Для работы с чисто PCIe не скажу точно - давно не работал но должно быть похоже так как i_uut.i_pcie_sys.i_xdma.inst.pcie3_ip_i это обычная голая PCIe корка.
Для синтеза и сима с GT* опция None, для сима с PIPE -Enable external PIPE.

Вот как раз запустил в 18.2 сим XDMA с PIPE - Оказалось что предварительная компиляция корки в библиотеку и компиляция BD в проекте идет с разными параметрами внутренних интерфейсов поэтому при запуске валится сим если последовательность библиотек для поиска модулей сначала находит корку в предварительно скомпилированной библиотеке . Ну а вообще вивадовская каша с библиотеками это отдельный "плач Ярославны"

Разница в разы - когда включен PIPE симулятор то GT убираются из структуры корки полностью.

Успехов! Rob.

Снимаю шляпу! А чем всё-таки штатный пример не устроил? Там вроде бы тоже RP сделан на той же корке в режиме Root Complex, и типа "прикладной код" написан, который выполняет всю работу - енумерацию, передачу и приём TLP. Код, конечно, местами некрасиво написан - чего стоит только компоновка через `include, но это, имхо, можно малой кровью переформатировать.





Я немного запутался: так вы используете вариант с force или с внешними портами?


Там компиляция этой корки валится с ошибками - что-то там на языковые конструкции жалуется? Как вы это обошли?


Я все три варианта прогнал "из коробки", все вяжутся через GT. В каком случае оно GT убирает полностью? Когда defparam'ами установишь значения параметров?

Приветствую!
Лучший способ разобраться что и как - переписать все по-своему. Я и начал с "малой крови" делая врапперы над этим франкинштейном и переписывая все более менее модульно на SV. В результате получился свой монстрик Потом появился AXI-PCIe bridge и стало немного проще если не надо работать на уровне TLP.

У меня PCie корки в основном ставятся на BD. Корку для сима генерирую с Enable External PIPE Interface но порты ext_pipe наружу BD не вытягиваю они висят в BD не подключенные. И цепляюсь к ним из TB через force. Для P&R перегенерирую корку с NONE при этом не надо ничего больше править на BD.

Пока благородя помощи efq из темы про microblaze_v10

Ну да - defparam *.inst.pcie3_ip_i.inst.EXT_PIPE_SIM = "TRUE"|""FALSE; как раз отключает/включает GT PHY внутри PCie корки.


Удачи! Rob.

Понятно. И сколько времени ушло на это? Или сложно оценить, т.к. делалось постепенно, от проекта к проекту, пока не вырисовалось более-менее удобоваримое и полностью управляемое своё?



Ага, теперь почти совсем понятно. А почему вторую опцию не используете (Enable PIPE Simulation), раз всё равно внешний PIPE интерфейс не юзается, а просто болтается в воздухе - какой смысл его генерить? По ходу, вторая опция была бы как раз именно то, что и надо. Не так?


На уровне исходников поправили?

Да - это был не отдельный таск. В общем возился где-то месяца 3-4 в фоновом режиме, разбираясь со всем что есть для PCIe и переписывая пример Xilinx. Вариант с AXI-PCie bridge в основном сделал где-то за месяц.

Уже и не вспомню. Там все что то менялось с сигналами для разных версий PCie и разных чипов. Да и разницы нет - главное как-то устаканилось в методике применения.

Нет - вариант от efq компилируется без этой ошибки. Причем по коду непонятно что как может вызывать эту ошибку в оригинале.

Удачи! Rob.

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