Requester Request Interface - 4.4 English

s_axis_rq_tdata

Input

DW

Requester reQuest Data bus.

This input contains the requester-side request 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_rq_tuser

Input

60

Requester reQuest User Data.

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

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

s_axis_rq_tlast

Input

1

TLAST Indication for Requester reQuest Data.

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 application must set this bit in the first cycle of the transfer.

s_axis_rq_tkeep

Input

DW/32

TKEEP Indication for Requester reQuest Data.

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 application 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_tkeep 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 (in both 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_rq_tvalid

Input

1

Requester reQuest Data Valid.

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

Output

4

Requester reQuest 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_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 application must maintain the data on the bus and keep the valid signal asserted until the core has asserted the ready signal.

You can assign all 4 bits to 1 or 0.

pcie_rq_seq_num

Output

4

Requester reQuest TLP transmit sequence number.

You can optionally use this output to track the progress of the request in the core transmit pipeline. To use this feature, provide a sequence number for each request on the seq_num[3:0] bus. The core outputs this sequence number on the pcie_rq_seq_num[3:0] output when the request TLP has reached a point in the pipeline where a Completion TLP from the user application cannot pass it. This mechanism enables you to maintain ordering between Completions sent to the CC interface of the core and Posted requests sent to the requester request interface. Data on the pcie_rq_seq_num[3:0] output is valid when pcie_rq_seq_num_vld is High.

pcie_rq_seq_num_vld

Output

1

Requester reQuest TLP transmit sequence number valid.

This output is asserted by the core for one cycle when it has placed valid data on pcie_rq_seq_num[3:0].

pcie_rq_tag

Output

6

Requester reQuest Non-Posted tag.

When tag management for Non-Posted requests is performed by the core (AXISTEN_IF_ENABLE_CLIENT_TAG is 0), this output is used by the core to communicate the allocated tag for each Non-Posted request received. The tag value on this bus is valid for one cycle when pcie_rq_tag_vld is High. You 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_vld by the core to provide the allocated tag for the request. Meanwhile, the user application can continue to send new requests. The tags for requests are communicated on this bus in FIFO order, so the user application can easily associate the tag value with the request it transferred.

pcie_rq_tag_vld

Output

1

Requester reQuest Non-Posted tag valid.

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_tag output.

3:0

first_be[3:0]

4

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. For Memory Reads,
I/O Reads, and Configuration Reads, these four 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.

7:4

last_be[3:0]

4

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. For Memory Reads of two Dwords or more, these four bits indicate the valid bytes to be read in the last Dword of the block of data. For Memory Reads and Writes of one DW transfers and zero length transfers, these bits should be 0s. For Memory Writes of two 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.

10:8

addr_offset[2:0]

3

When the address-aligned mode is in use on this interface, the user application must provide the byte lane number where the payload data begins on the data bus, modulo 4, on this sideband bus. This enables the core to determine the alignment of the data block being transferred.

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, this field must always be set to 0.

In Root Port configuration, Configuration Packets must always be aligned to DW0, and therefore for this type of packets, this field must be set to 0 in both alignment modes.

11

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.

You can assert this signal in any cycle during the transfer. You 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 application 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, when asserted, it should not be deasserted until s_axis_rq_tready is High. Discontinue is not supported for Non-Posted TLPs. The user logic can assert this signal in any cycle except the first cycle during the transfer.

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 Advanced Error Reporting (AER).

12

tph_present

1

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.

This bit must be permanently tied to 0 if the TPH capability is not in use.

14:13

tph_type[1:0]

2

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.

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

15

tph_indirect_tag_en

1

When this bit is set, the core uses the lower bits of tph_st_tag[7:0] as an index into its Steering Tag Table, and inserts the tag from this location in the transmitted request TLP.

When this bit is 0, the core uses the value on tph_st_tag[7:0] directly as the Steering Tag.

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.

This bit can be set to any value if tph_present is set to 0.

23:16

tph_st_tag[7:0]

8

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.

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

27:24

seq_num[3:0]

4

You can optionally supply a 4-bit sequence number in this field to keep track of the progress of the request in the core transmit pipeline. The core outputs this sequence number on its pcie_rq_seq_num[3:0] output when the request TLP has progressed to a point in the pipeline where a Completion TLP 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 application is not monitoring the pcie_rq_seq_num[3:0] output of the core.

59:28

parity

32

Odd parity for the 256-bit data.

When parity checking is enabled in the core, the user logic must set bit i of this bus to the odd parity computed for byte i of s_axis_rq_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.