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

Подскажите пожалуйчта, как из пользовательской логики ПЛИС можно прочитать значение регистров BAR0 (1-5)?

Что такое значение регистров BAR и зачем его читать? https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%...D0%B2%D0%BE_PCI Base Address Register

От хоста просто приходит некий пакет. Некоторые (если не все) IP ядра дают сигнал типа bar hit - показывают, в какой именно BAR (если вообще попал) и его диапазон попал адрес из пакета. Но вообще-то, какой смысла устройству знать значение этого регистра? Этот адрес имеет значение для хоста, а не устройства. Пришел пакет например чтения, и у него есть смещение - значит мы понимаем что хотел хост.

Я может уже забывать начал, но мне никогда не надо было знать значение BAR непосредственно...

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


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

Что такое значение регистров BAR и зачем его читать? https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%...D0%B2%D0%BE_PCI Base Address Register

От хоста просто приходит некий пакет. Некоторые (если не все) IP ядра дают сигнал типа bar hit - показывают, в какой именно BAR (если вообще попал) и его диапазон попал адрес из пакета. Но вообще-то, какой смысла устройству знать значение этого регистра? Этот адрес имеет значение для хоста, а не устройства. Пришел пакет например чтения, и у него есть смещение - значит мы понимаем что хотел хост.

Я может уже забывать начал, но мне никогда не надо было знать значение BAR непосредственно...

 

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

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


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

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

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

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


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

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

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

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


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

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

...

Только не очень понятно, каким образом эмулируется на функциональном моделировании физический уровень - ясно, что там нет смысла трансиверы изображать, но хотя бы их функциональность надо. В доках Xilinx упоминается некий PIPE - Physical Interface for PCI Express, который, вроде, и берёт на себя эту задачу. Но что это и как использовать, пока не знаю. Кто в курсе темы, поделитесь опытом, советами?

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

Если использовать для симуляции root-complex BFM такую же корку от Xilinx то особых проблем для коннекта с PIPE нет.

 

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

// Full path to the tested PCIe end_point
`define EP_INST i_top.i_pcie_sys.i_xdma.inst.pcie3_ip_i.inst
`define EP_PIPE i_top.i_pcie_sys.i_xdma.inst.pcie3_ip_i

`ifdef _ENABLE_GT_
 parameter PIPE_SIM                     = "FALSE";
 defparam `EP_INST.EXT_PIPE_SIM         = "FALSE";
 defparam `EP_INST.PL_EQ_BYPASS_PHASE23 = "FALSE";
`else
 parameter PIPE_SIM                     = "TRUE";
 defparam `EP_INST.EXT_PIPE_SIM         = "TRUE";
 defparam `EP_INST.PL_EQ_BYPASS_PHASE23 = "TRUE";
`endif

// PCIe root-complex BFM  (and path to the Xilinx root_complex PCIe instance)  
`define RP_PIPE RP.i_rp_tb.i_axi_pcie3
root_complex_bfm #(.PIPE_SIM(PIPE_SIM), ...) RP(.pcie_clk_p(rp_clk_p), ..., mgt_rx_p(rp_rx_p[0]), ..., mgt_tx_p(rp_rx_p[0]), ...);
...
if (PIPE_SIM=="TRUE") begin
 initial begin
   force `EP_PIPE.common_commands_in =`RP_PIPE.common_commands_out;
   force `EP_PIPE.pipe_rx_0_sigs   =`RP_PIPE.pipe_tx_0_sigs     ;
   ...
   force `RP_PIPE.common_commands_in =`EP_PIPE.common_commands_out;
   force `RP_PIPE.pipe_rx_0_sigs   =`EP_PIPE.pipe_tx_0_sigs     ;
   ...
 end
end
// tested BD module
pcie_sys  i_pcie_sys (.pcie_clk_p(rp_clk_p), ..., mgt_rx_p(rp_tx_p[0]), ..., mgt_tx_p(rp_rx_p[0]), ...);
...
initial begin
 RP.rp_bfm.reset();
 wait (RP.rp_bfm.init_complete);
 ...
end

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

 

Удачи! Rob.

 

 

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


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

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

 

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

Если использовать для симуляции root-complex BFM такую же корку от Xilinx то особых проблем для коннекта с PIPE нет.

 

Вот тут начинаются непонятности. Изучение темы 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 ядра есть следующая опция:

 

post-1343-1531211269_thumb.png

 

о чём в доке (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, время прогона одинаковое. Т.ч. по факту оно ни на что не влияет. Что-то сделал не так?

 

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

 

В симуляции с PIPE в основном сложности с подключением веревок интерфейсов.

 

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

 

Ну и некоторые нюансы с настройкой параметров для PCIe корки для работы с симуляцией PIPE (чтоб не ждать долго инициализации линка)

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

 

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

 

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

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


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

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

...

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

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

 

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

...

2 Enable Pipe Simulation: When selected, this option generates the core that can be simulated with PIPE interfaces connected. This ...

3 Enable External PIPE Interface: When selected, this option enables an external third-party bus functional model (BFM) to connect ...

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

Это как раз та "сложность" подключения веревок" Как я понял все это безобразие - так как PIPE интерфейс нужен

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

 

Такой интерфейс появляется в третьем случае, про который прямо сказано, что это для коннекта с "external third-party bus functional model". Изучая ваш шаблон, пришёл к выводу, что вы-то как раз этот вариант и используете. Или нет? Судя по сигналам, таки да. :)
И да и нет. Так как изначально я цеплялся к PIPE вариантом force - так как PCIe у меня не всегда близко к топу дизайна то мне лень страдать вытаскиванием PIPE интереса наружу. Поэтому такой вот шаблон - куда бы нелегкая не занесла PCIe я поменяв путь к ней в `define подключусь к висящим там PIPE веревкам.

Но тогда не понятно, откуда взялась BFM от Xilinx для этого варианта, если они сами отсылают к сторонним. Кстати, апноту, а которой они отсылают (XAPP1184), изучил, там всё более-менее понятно, только вот самой модели тоже нет и ссылка к ней [очевидно, давно] протухла. Да и не больно-то и хотелось. :)
Эта BFM взялась из отвращения "уважения" к тому примеру который дает Xilinx ;) Сейчас внутри это обычная AXI-PCie bridge (x8 gen3) корка в режиме root-complex к которой прикручен писаный на sv BFM имитирующий работу CPU. С основными прибамбасами по инициализации PCIe, BAR, чтению/записи регистров, системной памяти, обработке прерываний, XDMA, и.т.д. Была мысль прикрутить через DPI прослойку для отладки софта и драйверов. Я как то пытался прикручивать к PIPE внешную BFM DrivExpress - и даже заработала - но функционал оказался бякой.

 

Я пробовал все три варианта. Во всех случаях соединение идёт через GT, время прогона одинаковое. Т.ч. по факту оно ни на что не влияет. Что-то сделал не так?
А это как раз "некоторые нюансы" с настройкой параметров для PCIe - То что корка была сгенерирована с PIPE интерфейсом это не значить что она готова с ним работать :wacko: Надо подправить некие внутренние параметры модулей чтобы PIPE заработал ;) как раз это и делается через defparam...

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

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

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

Это больше 2 чем 3 вариант. Для 3 нужно вытягать шины наружу в TB и подключать их как обычные порты.

Force позволяет подключится к цепи внутри дизайна вместо имеющегося источника. То есть когда сгенерировал на BD корку с PIPE интересом но никуда его не подключил то Vivado по умолчанию на неподключенные входы цепляет 0. Force отцепляет этот 0 и подключает ко входам выходы PIPE из root-complex BFM.

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

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


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

Уточните версию софта - судя по картинке это гдето 2016.*

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

 

Это как раз та "сложность" подключения веревок" Как я понял все это безобразие - так как PIPE интерфейс нужен

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

Я правильно понял, что раньше (совсем раньше) было две опции: 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), а реально работают только первая (для синтеза) и третья (для симулятора). А вторая опция по сути даёт то же что и первая. Так?

 

Эта BFM взялась из отвращения "уважения" к тому примеру который дает Xilinx ;) Сейчас внутри это обычная AXI-PCie bridge (x8 gen3) корка в режиме root-complex к которой прикручен писаный на sv BFM имитирующий работу CPU. С основными прибамбасами по инициализации PCIe, BAR, чтению/записи регистров, системной памяти, обработке прерываний, XDMA, и.т.д.

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

 

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

 

А это как раз "некоторые нюансы" с настройкой параметров для PCIe - То что корка была сгенерирована с PIPE интерфейсом это не значить что она готова с ним работать :wacko: Надо подправить некие внутренние параметры модулей чтобы PIPE заработал ;) как раз это и делается через defparam...

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

 

  defparam `EP_INST.EXT_PIPE_SIM         = "FALSE";
  defparam `EP_INST.PL_EQ_BYPASS_PHASE23 = "FALSE";

 

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

 

parameter PL_FAST_TRAIN       = "FALSE", // Simulation Speedup

 

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

 

Это больше 2 чем 3 вариант. Для 3 нужно вытягать шины наружу в TB и подключать их как обычные порты.

Force позволяет подключится к цепи внутри дизайна вместо имеющегося источника. То есть когда сгенерировал на BD корку с PIPE интересом но никуда его не подключил то Vivado по умолчанию на неподключенные входы цепляет 0. Force отцепляет этот 0 и подключает ко входам выходы PIPE из root-complex BFM.

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

 

Пользую QuestaSim 10.4e. Сейчас смотрю что и как с 18.2 Вроде компилирует - но есть всего 1 ошибка при компиляции как раз в XDMA. Как мне кажется пока не связанная с криптованием.

Да, подтверждаю, 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), то они просто болтаются там в статике и никому не мешают?

 

 

 

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


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

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

 

Я правильно понял, что раньше (совсем раньше) было две опции: 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 скрипт при генерации корки вырезает кусок RTL для синтеза. И наоборот.

Может это и поправили в 18 версии но пока некогда ковырятся проверять.

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

 

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

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

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

Код у Xilinx старый - видно что писан еще во времена голого verilog отсюда такая громоздкая структура.

А хотелось чтобы для user было типа такого -

cs_rp_bfm rp_bfm; //RP bfm class
cs_cpu cpu_bus;    //CPU bus class
initial begin
  rp_mem_api =new("RP_API",i_ddr_axi_mc_sim.axi_mem); // API to system memory 
  rp_cfg_local  =new("RP_cfg_local");  // API to RP local configuration space read/write
  // RP BFM root_complex 
  rp_rc_bfm    =new("RP root-complex", rp_cfg_local, rp_mem_api, ...);
  ...
  rp_rc_bfm.system_reset();
  rp_rc_bfm.rp_init();
  rp_rc_bfm.rp_enumerate();
  $display("[%t] : Root-port initialization done ...",$time);
end

task test_ep0 ...
  rev_date =new("REV_DATE",  RP.cpu_bus, rp_rc_bfm.ep[0].bar[0]+REV_DATE_ADDR, "0x%08x"); // endpoint register
  rev_date.display(); // rev_date.set(..),  rev_get.get(..), ...

 

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

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

Этого достаточно для работы с 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 в проекте идет с разными параметрами внутренних интерфейсов поэтому при запуске валится сим если последовательность библиотек для поиска модулей сначала находит корку в предварительно скомпилированной библиотеке :(. Ну а вообще вивадовская каша с библиотеками это отдельный "плач Ярославны"

 

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

 

Успехов! Rob.

 

 

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


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

 

Сам. В основном время ушло на разбор что нужно, что и как делаетя в примерах работы с PCIe Xilinx (и Алтера тоже).

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

 

Да - Если включаеш любую опцию Enable PIPE Simulation скрипт при генерации корки вырезает кусок RTL для синтеза. И наоборот.

Может это и поправили в 18 версии но пока некогда ковырятся проверять.

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

 

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

Для синтеза и сима с GT* опция None, для сима с PIPE -Enable external PIPE.

 

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

 

Вот как раз запустил в 18.2 сим XDMA с PIPE -

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

 

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

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

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


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

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

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

 

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

 

Там компиляция этой корки валится с ошибками - что-то там на языковые конструкции жалуется? Как вы это обошли?
Пока благородя помощи efq из темы про microblaze_v10 :)

 

Я все три варианта прогнал "из коробки", все вяжутся через GT. В каком случае оно GT убирает полностью? Когда defparam'ами установишь значения параметров?
Ну да - defparam *.inst.pcie3_ip_i.inst.EXT_PIPE_SIM = "TRUE"|""FALSE; как раз отключает/включает GT PHY внутри PCie корки.

module rp_tb_i_axi_pcie3_0_pcie3_ip_pcie3_uscale_core_top ...
  parameter EXT_PIPE_SIM = "FALSE",  // This Parameter has effect on running PIPE simulation by dis-connecting GTs and synthesis by connecting GTs.

 

Удачи! Rob.

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


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

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

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

 

 

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

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

 

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

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

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


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

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

 

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

 

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

 

Удачи! Rob.

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


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

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

 

...

 

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

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

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


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

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

Есть IP-ядро UltraScale FPGA Gen3 Integrated Block for PCI Express. Необходимо обращаться к памяти, расположенной за root complex.

Правильно ли я понимаю, что на одиночный запрос Memory Read Request может прийти как целый одиночный пакет с данными, так и несколько "дробленных", причем в произвольном порядке?

Какая будет граница данных при дроблении?

Как правильно организовать сбор принятых данных?

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


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

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

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

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

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

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

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

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

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

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