08-27-2019 06:15 PM
I am using the "ultrascale+ device integrated block for PCIe v1.3" in xcvu37p. The debug port of "configuration management interface" (cfg_mgmt_*) is enabled when creating its IP wrapper. By using the cfg_mgmt_* port, I am trying to access the PCIe configuration space before the PCIe bus boot up so that I can change the pcie bus link up width and rate configurations for testing. In the simulation test, the cfg_mgmt_* port read acess behaviors as expected, but the write access is not. For example, after a successful cfg_mgmt_* port write to a register in the PCIe configuration space, the register value does not get changed.
If the registers in the PCIe configuration spcae are writeable through the cfg_mgmt_* port? If not, then is it possible to change the lane width and rate capabilites settings in the configuration space before PCIe bus boot up?
08-28-2019 02:04 AM
If it cannot be written in the simulation, it will be hard coded. Since these can be negotiated with the connection partner, if you want to decide in advance, you need to select the speed and width that are possible when generating the IP.
08-28-2019 10:27 AM
It is hard to belive that the registers in the PCIe cobfiguration space are hardcoded, since almost all the PCIe IPs in SOC market are not doing that way. Do you mean only the register I tested is hardcoded or all the registers in the PCIe configuration space are hardcoded? Xilinx document, PG213 v1.3, says the cfg_mgmt_* port can do write to the registers in the configuration space, but it does not say which registers are read-only. If any registers is hardcoded, the Xilinx document should spec it. The docment also says to assert cfg_mgmt_debug_access=1'b1, user should be able to write the type-1 read-only registers (in my test I assert cfg_mgmt_debug_access=1'b1 all the time).
The UG213 also mentined the Hardware Debug ports, the PCIe DRP Ports is available. For my undersatanding, this port should be able to re-configure the PCIe code with all new parameters in run time. But the document does not provide any details about the DRP port, like the bus protocol and the register mapping. Where can I find more information about the PCIe DRP port?
08-29-2019 12:23 AM
Could you let me know the specific registers that you cannot write access to?
08-29-2019 10:18 AM
I would like to modify two registers in the PCIe configuration space through debugging port before the PCIe bus boot up in run time (many SOC designs work in that way),
1) the first one is the "Link Capabilities Register" in the PCIe capability structure, offset address 0x0C. In my case, the PCIe Capability Structure is located in offset 0x70 in the linked list of capabilites, so the absolute offset address is 0x7C. I would like to change the bits field of "Max LInk Speed" or "Max Link Width".
2) the second one is the "Link Capbilities 2 Register" in the same structure at the offset address 0x2C. I would like to change the bits field of "Supported Speeds Vector".
Since the cfg_mgmt_* port is opertaing at the PCIe core's "user_clk", which may not be running before PCIe bus boot up, so I think I have to use the DRP port to change the register settings. The PCIe IP wizard allows user to enable the PCIe DRP Port, but I could not find a user-guide for using it. Please help.
09-02-2019 05:16 PM
The two capbilities registers are difined as Read Only by PCI Expresss Base SPecification.
09-03-2019 05:40 PM
The RO attributes shown in the spec you listed are for PCIe link master side when using "configuration read/write" link transactions. The spec does not apply for the IP register accessing from the "backdoor" debug ports, like the cfg_mgmt port memtioned in UG213 page 49. Especially for RP application, these registers need to be programmed through backdoor before PCIe bus boot up.
How about the PCIe DRP Port spec I requested before? I believe that these register values can be re-configured in run-time through the DRP port. In the PCIE4CE wrapper created from Vivado, the PCIe link rate and width are programmed using the parameters of PL_LINK_CAP_MAX_LINK_SPEED and PL_LINK_CAP_MAX_LINK_WIDTH. So the DRP port must be able to re-write them. If you like I can create a new request case for getting the PCIe DRP Port spec.