Configuration Control Interface - 1.0 English

In RP mode, assertion transitions LTSSM to hot reset state, active-High.

In EP mode, assertion indicates that EP has transitioned to the hot reset state, active-High.

When this input is set to 0 in the Endpoint mode, the core generates a CRS Completion in response to Configuration Requests. This port should be held deasserted when the core configuration registers are loaded from the DRP due to a change in attributes. This prevents the core from responding to Configuration Requests before all the registers are loaded. This input can be High when the power-on default values of the Configuration registers do not need to be modified before Configuration space enumeration. This input is not applicable for Root Port mode.

Indicates the value that should be transferred to the Device Serial Number Capability on PF0. Bits [31:0] are transferred to the first (Lower) Dword (byte offset 0x4h of the Capability), and bits [63:32] are transferred to the second (Upper) Dword (byte offset 0x8h of the Capability). If this value is not statically assigned, the user application must pulse user_cfg_input_update after it is stable. After the user logic updates cfg_dsn, the new cfg_dsn should appear on the Extended Configuration Space. No additional qualifying control signal is required.

Configuration Downstream Bus Number

Downstream Port: Provides the bus number portion of the Requester ID (RID) of the Downstream Port. This is used in TLPs generated inside the core, such as UR Completions and Power-management messages; it does not affect TLPs presented on the AXI interface.

Upstream Port: No role.

Downstream Port: Provides the device number portion of the RID of the Downstream Port. This is used in TLPs generated inside the core, such as UR Completions and Power-management messages; it does not affect TLPs presented on the TRN interface.

Upstream Port: No role.

Downstream Port: Provides the function number portion of the RID of the Downstream Port. This is used in TLPs generated inside the core, such as UR Completions and power-management messages; it does not affect TLPs presented on the TRN interface.

Upstream Port: No role.

You must assert this input to the core for one cycle in response to the assertion of cfg_power_state_change_interrupt, when it is ready to transition to the low-power state requested by the configuration write request. The user application can permanently hold this input High if it does not need to delay the return of the completions for the configuration write transactions, causing power-state changes.

The core asserts this output when the power state of a physical or virtual function is being changed to the D1 or D3 states by a write into its Power Management Control register. The core holds this output High until the user application asserts the cfg_power_state_change_ack input to the core. While cfg_power_state_change_interrupt remains High, the core does not return completions for any pending configuration read or write transaction received by the core. The purpose is to delay the completion for the configuration write transaction that caused the state change until the user application is ready to transition to the low-power state. When cfg_power_state_change_interrupt is asserted, the function number associated with the configuration write transaction is provided on the cfg_ext_function_number[7:0] output. When the user application asserts cfg_power_state_change_ack, the new state of the function that underwent the state change is reflected on cfg_function_power_state (for PFs) or the cfg_vf_power_state (for VFs) outputs of the core.

Provides the port number field in the Link Capabilities register.

The user application activates this input for one cycle to indicate a correctable error detected within the user logic that needs to be reported as an internal error through the PCI Express Advanced Error Reporting (AER) mechanism. In response, the core sets the Corrected Internal Error Status bit in the AER Correctable Error Status register of all enabled functions, and also sends an error message if enabled to do so. This error is not considered function-specific.

In the Endpoint mode, the Block activates this output for one cycle when it has detected a correctable error and its reporting is not masked. When multiple functions are enabled, this is the logical OR of the correctable error status bits in the Device Status Registers of all functions.

In the Endpoint mode, the block activates this output for one cycle when it has detected a fatal error and its reporting is not masked. When multiple functions are enabled, this output is the logical OR of the fatal error status bits in the Device Status Registers of all functions.

In the Root Port mode, this output is activated on detection of a local fatal error, when its reporting is not masked. This output does not respond to any errors signaled by remote devices using PCI Express error messages. These error messages are delivered to the user through the message interface.

In the Endpoint mode, the block activates this output for one cycle when it has detected a non fatal error and its reporting is not masked. When multiple functions are enabled, this output is the logical OR of the non fatal error status bits in the Device Status Registers of all functions.

In the Root Port mode, this output is activated on detection of a local non fatal error, when its reporting is not masked. This output does not respond to any errors signaled by remote devices using PCI Express error messages. These error messages are delivered through the message interface.

The user application activates this input for one cycle to indicate a uncorrectable error detected within the user logic that needs to be reported as an internal error through the PCI Express Advanced Error Reporting mechanism. In response, the core sets the uncorrected Internal Error Status bit in the AER Uncorrectable Error Status register of all enabled functions, and also sends an error message if enabled to do so. This error is not considered function-specific.

4 in PL-PCIe4

1 in PL-PCIe5

The user application must assert this input when it has completed the reset operation of the Virtual Function. This causes the core to deassert cfg_flr_in_process for physical function i and to re-enable configuration accesses to the physical function. The core issues CRS to configurations requests to a particular Physical Function till cfg_flr_done is not asserted when cfg_flr_in_process =1 for that Physical Function.

Function Level Reset Complete in PL-PCIe5

The user application must assert this input when it has completed the reset operation of the cfg_flr_done_func_num Function that received a CfgWr TLP writing a 1 to Function Level Reset. This causes the core to re-enable configuration accesses to the Function.

The user application must assert this input when it has completed the reset operation of the Virtual Function. This causes the core to deassert cfg_vf_flr_in_process for function i and to re-enable configuration accesses to the virtual function. The core issues CRS to configuration requests to a particular Virtual Function till cfg_vf_flr_done is not asserted when cfg_vf_flr_in_process = 1 for that Virtual Function.

The user application drives a valid Virtual Function number on this input along with asserting cfg_vf_flr_done when the reset operation of Virtual Function i completes.

Valid entries are 8'h04-8'hFF for VF0-VF251. Values 8'h00-8'h03 are reserved.

The core asserts bit i of this bus when the host initiates a reset of physical function i through its FLR bit in the configuration space. The core continues to hold the output High until the user sets the corresponding cfg_flr_done input for the corresponding physical function to indicate the completion of the reset operation.

The core asserts bit i of this bus when the host initiates a reset of virtual function i though its FLR bit in the configuration space. The core continues to hold the output High until the user sets the cfg_vf_flr_done input and drives cfg_vf_flr_func_num with the corresponding function to indicate the completion of the reset operation.

Indicates the value that should be transferred to the PCI Capability Structure Vendor ID field on all PFs.

Indicates the value that should be transferred to the Type 0 PCI Capability Structure Subsystem Vendor ID field on all PFs.

Indicates the value that should be transferred to the PCI Capability Structure Device ID field on PF0.

Indicates the value that should be transferred to the PCI Capability Structure Device ID field on PF1.

Indicates the value that should be transferred to the PCI Capability Structure Device ID field on PF2.

Indicates the value that should be transferred to the PCI Capability Structure Device ID field on PF3.

Indicates the value that should be transferred to the PCI Capability Structure Revision ID field on PF0.

Indicates the value that should be transferred to the PCI Capability Structure Revision ID field on PF1.

Indicates the value that should be transferred to the PCI Capability Structure Revision ID field on PF2.

Indicates the value that should be transferred to the PCI Capability Structure Revision ID field on PF3.

Indicates the value that should be transferred to the Type 0 PCI Capability Structure Subsystem ID field on PF0.

Indicates the value that should be transferred to the Type 0 PCI Capability Structure Subsystem ID field on PF1.

Indicates the value that should be transferred to the Type 0 PCI Capability Structure Subsystem ID field on PF2.

Indicates the value that should be transferred to the Type 0 PCI Capability Structure Subsystem ID field on PF3.