Completer Completion Interface - 4.4 English

UltraScale Devices Gen3 Integrated Block for PCI Express LogiCORE IP Product Guide (PG156)

Document ID
PG156
Release Date
2023-11-24
Version
4.4 English

The Completer Completion (CC) interface are the ports through which completions generated by the user application responses to the completer requests are transmitted. You can process all Non-Posted transactions as split transactions. That is, the CC interface can continue to accept new requests on the requester completion interface while sending a completion for a request. Table: Completer Completion Interface Port Descriptions defines the ports in the CC interface of the core. In the Width column, DW denotes the configured data bus width (64, 128, or 256 bits).

Table 2-5: Completer Completion Interface Port Descriptions

Port

Direction

Width

Description

s_axis_cc_tdata

Input

DW

Completer Completion Data bus.

Completion data from the user application to the core. Only the lower 128 bits are used when the interface width is 128 bits, and only the lower 64 bits are used when the interface width is 64 bits.

s_axis_cc_tuser

Input

33

Completer Completion User Data.

This set of signals contain sideband information for the TLP being transferred. These signals are valid when s_axis_cc_tvalid is High.

Table: Sideband Signal Descriptions in s_axis_cc_tuser describes the individual signals in this set.

s_axis_cc_tlast

Input

1

TLAST indication for Completer Completion Data.

The user application must assert this signal in the last cycle of a packet to indicate the end of the packet. When the TLP is transferred in a single beat, the user application must set this bit in the first cycle of the transfer.

s_axis_cc_tkeep

Input

DW/32

TKEEP indication for Completer Completion Data.

The assertion of bit i of this bus during a transfer indicates to the core that Dword i of the s_axis_cc_tdata bus contains valid data. Set this bit to 1 contiguously for all Dwords starting from the first Dword of the descriptor to the last Dword of the payload. Thus, s_axis_cc_tdata must be set to all 1s in all beats of a packet, except in the final beat when the total size of the packet is not a multiple of the width of the data bus (both in Dwords). This is true for both Dword-aligned and address-aligned modes of payload transfer.

Bits [7:4] of this bus are not used by the core when the interface width is configured as 128 bits, and bits [7:2] are not used when the interface width is configured as 64 bits.

s_axis_cc_tvalid

Input

1

Completer Completion Data Valid.

The user application must assert this output whenever it is driving valid data on the s_axis_cc_tdata bus. The user application must keep the valid signal asserted during the transfer of a packet. The core paces the data transfer using the s_axis_cc_tready signal.

s_axis_cc_tready

Output

4

Completer Completion Data Ready.

Activation of this signal by the core indicates that it is ready to accept data. Data is transferred across the interface when both s_axis_cc_tvalid and s_axis_cc_tready are asserted in the same cycle.

If the core deasserts the ready signal when the valid signal is High, the user application must maintain the data on the bus and keep the valid signal asserted until the core has asserted the ready signal.

Table 2-6: Sideband Signal Descriptions in s_axis_cc_tuser

Bit Index

Name

Width

Description

0

discontinue

1

This signal can be asserted by the user application during a transfer if it has detected an error (such as an uncorrectable ECC error while reading the payload from memory) in the data being transferred and needs to abort the packet. The core nullifies the corresponding TLP on the link to avoid data corruption.

The user application can assert this signal during any cycle during the transfer. It can either choose to terminate the packet prematurely in the cycle where the error was signaled, or can continue until all bytes of the payload are delivered to the core. In the latter case, the core treats the error as sticky for the following beats of the packet, even if the user application deasserts the discontinue signal before the end of the packet.

The discontinue signal can be asserted only when s_axis_cc_tvalid is High. The core samples this signal only when s_axis_cc_tready is High. Thus, when asserted, it should not be deasserted until s_axis_cc_tready is High.

When the core is configured as an Endpoint, this error is also reported by the core to the Root Complex to which it is attached, using AER.

32:1

parity

32

Odd parity for the 256-bit data.

When parity checking is enabled in the core, user logic must set bit i of this bus to the odd parity computed for byte i of s_axis_cc_tdata. Only the lower 16 bits are used when the interface width is 128 bits, and only the lower 8 bits are used when the interface width is 64 bits.

When an interface parity error is detected, it is recorded as an uncorrectable internal error and the packet is discarded. According to the Base Spec 6.2.9, an uncorrectable internal error is an error that occurs within a component that results in improper operation of the component. The only method of recovering from an uncorrectable internal error is a reset or hardware replacement.

The parity bits can be permanently tied to 0 if parity check is not enabled in the core.