| 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 | 137 | 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:
|
| 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:
|
| 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]. |
| 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:
If a new TLP starts in the beat
following |
| 23:22 | is_sop0_ptr[1:0] | 2 | Indicates the position of the first byte of the
first TLP starting in this beat:
|
| 25:24 | is_sop1_ptr[1:0] | 2 | Indicates the position of the first byte of the
second TLP starting in this beat:
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:
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.
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.
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.
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.
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. |