Requester Request Interface - 1.3 English

UltraScale+ Devices Integrated Block for PCI Express Product Guide (PG213)

Document ID
PG213
Release Date
2023-10-19
Version
1.3 English
Table 1. Requester Request Interface Port Descriptions (512-bit Interface)
Name I/O Width Description
s_axis_rq_tdata I 512 Requester-side request data from the user application to the PCIe core.
s_axis_rq_tuser I 183 This is a set of signals containing sideband information for the TLP being transferred. These signals are valid when s_axis_rq_tvalid is High. The individual signals in this set are described in the following table.
s_axis_rq_tlast I 1 The user application must assert this signal in the last cycle of a TLP to indicate the end of the packet. When the TLP is transferred in a single beat, the user logic must set this bit in the first cycle of the transfer.

This input is used by the core only when the straddle option is disabled. When the straddle option is enabled, the core ignores the setting of this input, using instead the is_sop/is_eop signals in the s_axis_rq_tuser bus to determine the start and end of TLPs.

s_axis_rq_tkeep I 16 The assertion of bit i of this bus during a transfer indicates to the core that Dword i of the s_axis_rq_tdata bus contains valid data. The user logic must 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_rq_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 128b address-aligned modes of payload transfer.

The tkeep bits are valid only when straddle is not enabled on the RQ interface. When straddle is enabled, the core ignores the setting of these bits when receiving data across the interface. The user logic must set the is_sop/is_eop signals in the s_axis_rq_tuser bus in that case to signal the start and end of TLPs transferred over the interface.

s_axis_rq_tvalid I 1 The user application must assert this output whenever it is driving valid data on the s_axis_rq_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_rq_tready signal.
s_axis_rq_tready O 4 Activation of this signal by the PCIe core indicates that it is ready to accept data. Data is transferred across the interface when both s_axis_rq_tvalid and s_axis_rq_tready are asserted in the same cycle.

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

With this output port, each bit indicates the same value, so the user logic can use any of the bit.

pcie_rq_tag_vld0 O 1 The core asserts this output for one cycle when it has allocated a tag to an incoming Non-Posted request from the requester request interface and placed it on the pcie_rq_tag0 output. The bit is encoded as follows:
  • 0: No tags being provided in this cycle.
  • 1: A tag is presented on pcie_rq_tag0.
pcie_rq_tag_vld1 O 1 The core asserts this output for one cycle when it has allocated a tag to an incoming Non-Posted request from the requester request interface and placed it on the pcie_rq_tag1 output. The bit is encoded as follows:
  • 0: No tag is provided on pcie_rq_tag1 in this cycle.
  • 1: A tag is presented on pcie_rq_tag1.
pcie_rq_tag0 O 8 When tag management for Non-Posted requests is performed by the core (Enable Client Tag is unchecked in the IP customization GUI), this output is used by the core to communicate the allocated tag for each Non-Posted request received from the client. The tag value on pcie_rq_tag0 is valid for one cycle when pcie_rq_tag_vld0 is High. The client must copy this tag and use it to associate the completion data with the pending request.

There can be a delay of several cycles between the transfer of the request on the s_axis_rq_tdata bus and the assertion of pcie_rq_tag_vld0 by the core to provide the allocated tag for the request. The client can, meanwhile, continue to send new requests. The tags for requests are communicated on this bus in FIFO order. Therefore, the user application must associate the allocated tags with the requests in the order in which the requests were transferred over the interface.

When pcie_rq_tag0 and pcie_rq_tag1 are both valid in the same cycle, the value on pcie_rq_tag0 corresponds to the earlier of the two requests transferred over the interface.

pcie_rq_tag1 O 8 The description of this signal is the same as pcie_rq_tag0, except the tag value on pcie_rq_tag1 is valid for one cycle when pcie_rq_tag_vld1 is asserted.
pcie_rq_seq_num0 O 6 You can optionally use this output to keep track of the progress of the request in the core's transmit pipeline. To use this feature, the user application must provide a sequence number for each request on the s_axis_rq_seq_num0[5:0] bus. The core outputs this sequence number on the pcie_rq_seq_num0[5:0] output when the request TLP has progressed to a point in the pipeline where a Completion TLP from the client is not be able to pass it. This mechanism enables the client to maintain ordering between Completions sent to the completer completion interface of the core and Posted requests sent to the requester request interface.

Data on the pcie_rq_seq_num0[5:0] output is valid when pcie_rq_seq_num_ vld0 is High.

pcie_rq_seq_num1 O 6 This output is identical in function to that of pcie_rq_seq_num0. It is used to provide a second sequence number in the same cycle when a first sequence number is being presented on pcie_rq_seq_num0.

Data on the pcie_rq_seq_num1[5:0] output is valid when pcie_rq_seq_num_ vld1 is High.

pcie_rq_seq_num_vld0 O 1 This output is asserted by the core for one cycle when it has placed valid data on pcie_rq_seq_num0[5:0].
pcie_rq_seq_num_vld1 O 1 This output is asserted by the core for one cycle when it has placed valid data on pcie_rq_seq_num1[5:0].
Table 2. Sideband Signals in s_axis_rq_tuser (512-bit Interface)
Bit Index Name Width Description
7:0 first_be[7:0] 8 Byte enables for the first Dword. This field must be set based on the desired value of the First_BE bits in the Transaction-Layer header of the request TLP. first_be[3:0] corresponds to the byte enables for the first TLP starting in this beat, and first_be[7:4] corresponds to the byte enables for the second TLP starting in this beat (if present).

For Memory Reads, I/O Reads and Configuration Reads, these 4 bits indicate the valid bytes to be read in the first Dword. For Memory Writes, I/O Writes and Configuration Writes, these bits indicate the valid bytes in the first Dword of the payload.

The core samples this field in the first beat of a packet, when s_axis_rq_tvalid and s_axis_rq_tready are both High.

15:8 last_be[7:0] 8 Byte enables for the last Dword.

This field must be set based on the desired value of the Last_BE bits in the Transaction-Layer header of the TLP. last_be[3:0] corresponds to the byte enables for the first TLP starting in this beat, and last_be[7:4] corresponds to the byte enables for the second TLP starting in this beat (if present).

For Memory Reads and Writes of one DW transfers and zero length transfers, these bits should be 0s.

For Memory Reads of 2 Dwords or more, these 4 bits indicate the valid bytes to be read in the last Dword of the block of data. For Memory Writes of 2 Dwords or more, these bits indicate the valid bytes in the last Dword of the payload.

The core samples this field in the first beat of a packet, when s_axis_rq_tvalid and s_axis_rq_tready are both High.

19:16 addr_offset[3:0] 4 When 128b the address-aligned mode is in use on this interface, the user application must provide the offset where the payload data begins (in multiples of 4 bytes) on the data bus on this sideband bus. This enables the core to determine the alignment of the data block being transferred.

addr_offset[1:0] corresponds to the offset for the first TLP starting in this beat, and addr_offset[3:2] is reserved for future use.

The core samples this field in the first beat of a packet, when s_axis_rq_tvalid and s_axis_rq_tready are both High.

When the requester request interface is configured in the Dword-alignment mode, these bits must always be set to 0.

21:20 is_sop[1:0] 2 Signals the start of a new TLP in this beat. These outputs are set in the first beat of a TLP. When straddle is disabled, only is_sop[0] is valid. When straddle is enabled, the settings are as follows:
  • 00: No new TLP starting in this beat.
  • 01: A single new TLP starts in this beat. Its start position is indicated by is_sop0_ptr[1:0].
  • 11: Two new TLPs are starting in this beat. is_sop0_ptr[1:0] provides the start position of the first TLP and is_sop1_ptr[1:0] provides the start position of the second TLP.
  • 10: Reserved.

Use of this signal is optional for the user logic when the straddle option is not enabled, because a new TLP always starts in the beat following tlast assertion.

23:22 is_sop0_ptr[1:0] 2 Indicates the position of the first byte of the first TLP starting in this beat:
  • 00: Byte lane 0
  • 10: Byte lane 32
  • 01, 11: Reserved
25:24 is_sop1_ptr[1:0] 2 Indicates the position of the first byte of the second TLP starting in this beat:
  • 10: Byte lane 32
  • 00, 01, 11: Reserved.

This output is used only when the straddle option is enabled on the interface.

27:26 is_eop[1:0] 2 Signals that a TLP is ending in this beat. These outputs are set in the final beat of a TLP. When straddle is disabled, only is_eop[0] is valid. When straddle is enabled, the settings are as follows:
  • 00: No TLPs ending in this beat.
  • 01: A single TLP is ending in this beat. is_eop0_ptr[3:0] provides the offset of the last Dword of this TLP.
  • 11: Two TLPs are ending in this beat. is_eop0_ptr[3:0] provides the offset of the last Dword of the first TLP and is_eop1_ptr[3:0] provides the offset of the last Dword of the second TLP.
  • 10: Reserved.

Use of this signal is optional for the user logic when the straddle option is not enabled, because tlast Is asserted in the final beat of a TLP.

31:28 is_eop0_ptr[3:0] 4 Offset of the last Dword of the first TLP ending in this beat. This output is valid when is_eop[0] is asserted.
35:32 is_eop1_ptr[3:0] 4 Offset of the last Dword of the second TLP ending in this beat. This output is valid when is_eop[1] is asserted.
36 discontinue 1 This signal can be asserted by the user application during a transfer if it has detected an error 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 logic can assert this signal in any beat of a TLP except the first beat during its transfer. It can either choose to terminate the packet prematurely in the cycle where the error was signaled, or 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 logic deasserts the discontinue signal before the end of the packet.

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

When the straddle option is enabled on the RQ interface, the user should not start a new TLP in the same beat when a TLP is ending with discontinue asserted.

When the core is configured as an Endpoint, this error is also reported by the core to the Root Complex it is attached to, using Advanced Error Reporting (AER).

38:37 tph_present[1:0] 2 This bit indicates the presence of a Transaction Processing Hint (TPH) in the request TLP being delivered across the interface. The core samples this field in the first beat of a packet, when s_axis_rq_tvalid and s_axis_rq_tready are both High.
  • tph_present[0] corresponds to the first TLP starting in this beat.
  • tph_present[1] corresponds to the second TLP starting in this beat (if present).

These inputs must be permanently tied to 0 if the TPH capability is not in use.

42:39 tph_type[3:0] 4 When a TPH is present in the request TLP, these two bits provide the value of the PH[1:0] field associated with the hint. The core samples this field in the first beat of a packet, when s_axis_rq_tvalid and s_axis_rq_tready are both High.
  • tph_type[1:0] corresponds to the first TLP starting in this beat.
  • tph_type[3:2] corresponds to the second TLP starting in this beat (if present).

These bits can be set to any value if the corresponding tph_present bit is set to 0.

44:43 tph_indirect_tag_en[1:0] 2 When this bit is set, the core uses the lower bits of the tag presented on tph_st_tag as an index into its Steering Tag Table, and insert the tag from this location in the transmitted request TLP. When this bit is 0, the core uses the value on tph_st_tag directly as the Steering Tag.
  • tph_ indirect_tag_en[0] corresponds to the first TLP starting in this beat.
  • tph_ indirect_tag_en[1] corresponds to the second TLP starting in this beat (if present).

The core samples this bit in the first beat of a packet, when s_axis_rq_tvalid and s_axis_rq_tready are both High.

These inputs can be set to any value if the corresponding tph_present bit is set to 0.

60:45 tph_st_tag[15:0] 16 When a TPH is present in the request TLP, this output provides the 8-bit Steering Tag associated with the hint. The core samples this field in the first beat of a packet, when s_axis_rq_tvalid and s_axis_rq_tready are both High.
  • tph_st_tag[7:0] corresponds to the first TLP starting in this beat.
  • tph_ st_tag[15:8] corresponds to the second TLP starting in this beat (if present).

These inputs can be set to any value if the corresponding tph_present bit is set to 0.

66:61 seq_num0[5:0] 6 The user logic can optionally supply a 6-bit sequence number in this field to keep track of the progress of the request in the core’s transmit pipeline. The core outputs this sequence number on its pcie_rq_seq_num0 or pcie_rq_seq_num1 output when the request TLP has progressed to a point in the pipeline where a Completion TLP from the user logic is not able to pass it.

The core samples this field in the first beat of a packet, when s_axis_rq_tvalid and s_axis_rq_tready are both High.

This input can be hardwired to 0 when the user logic is not monitoring the pcie_rq_seq_num* outputs of the core.

72:67 seq_num1[5:0] 6 If there is a second TLP starting in the same beat, the user logic can optionally provide a 6-bit sequence number for this TLP on this input. This sequence number is used in the same manner as seq_num0.

The core samples this field in the first beat of a packet, when s_axis_rq_tvalid and s_axis_rq_tready are both High.

This input can be hardwired to 0 when the user logic is not monitoring the pcie_rq_seq_num* outputs of the core.

136:73 parity 64 Odd parity for the 512-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_rq_tdata.

On detection of a parity error, the core nullifies the corresponding TLP on the link and reports it as an Uncorrectable Internal Error.

These bits can be set to 0 if parity checking is disabled in the core.