| Name | Width | I/O | Description |
|---|---|---|---|
| pcie0_s_axis_rq_tdata pcie1_s_axis_rq_tdata | 1024 | I | Requester-side request data from the user application to the PCIe core. |
| pcie0_s_axis_rq_tuser pcie1_s_axis_rq_tuser | 373 | I | This is a set of signals containing sideband information for the TLP being transferred. These signals are valid when pcie(n)_s_axis_rq_tvalid is high. The individual signals in this set are described in the following table. |
| pcie0_s_axis_rq_tlast pcie1_s_axis_rq_tlast | 1 | I | 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. |
| pcie0_s_axis_rq_tkeep pcie1_s_axis_rq_tkeep | 32 | I | The assertion of bit i of this
bus during a transfer indicates to the core that Dword i of the pcie(n)_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,
pcie(n)_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 pcie(n)_s_axis_rq_tuser bus in that case to signal the start and end of TLPs transferred over the interface. |
| pcie0_s_axis_rq_tvalid pcie1_s_axis_rq_tvalid | 1 | I | The user application must assert this output whenever it is driving valid data on the pcie(n)_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 pcie(n)_s_axis_rq_tready signal. |
| pcie0_s_axis_rq_tready pcie1_s_axis_rq_tready | 1 | O | Activation of this signal by the PCIe core indicates that it is ready
to accept data. Data is transferred across the interface when both
pcie(n)_s_axis_rq_tvalid and pcie(n)_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. |
| Bit Index | Name | Width | Description |
|---|---|---|---|
| 15:0 | first_be[15:0] | 16 | Byte enables for the first Dword of the payload.
first_be[3:0] reflects the setting of the First Byte Enable bits in
the Transaction-Layer header of the first TLP in this beat;
first_be[7:4] reflects the setting of the First Byte Enable bits in
the Transaction-Layer header of the second TLP in this beat.
first_be[11:8] reflects the setting of the First Byte Enable bits in
the Transaction-Layer header of the third TLP in this beat; and
first_be[15:12] reflects the setting of the First Byte Enable bits
in the Transaction-Layer header of the fourth TLP in this beat. 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 pcie(n)_s_axis_rq_tvalid and pcie(n)_s_axis_rq_tready are both High. |
| 31:16 | last_be[15:0] | 16 | Byte enables for the last Dword. Byte enables for the last Dword of the payload. last_be[3:0] reflects the setting of the Last Byte Enable bits in the Transaction-Layer header of the first TLP in this beat; last_be[7:4] reflects the setting of the Last Byte Enable bits in the Transaction-Layer header of the second TLP in this beat. last_be[11:8] reflects the setting of the Last Byte Enable bits in the Transaction-Layer header of the third TLP in this beat; and last_be[15:12] reflects the setting of the Last Byte Enable bits in the Transaction-Layer header of the fourth TLP in this beat. 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 pcie(n)_s_axis_rq_tvalid and pcie(n)_s_axis_rq_tready are both High. |
| 47:32 | addr_offset[15:0] | 16 | 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[3:0] corresponds to the offset for the first TLP starting in this beat,addr_offset[7:4] is for second TLP, addr_offset[11:8] for third TLP and addr_offset[15:12] for fourth TLP The core samples this field in the first beat of a packet, when pcie(n)_s_axis_rq_tvalid and pcie(n)_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. |
| 51:48 | is_sop[3:0] | 4 | Signals the start of a new TLP in this beat. These outputs are set in
the first beat of a TLP. 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 a new TLP always starts in the beat following tlast assertion. |
| 53:52 | is_sop0_ptr[1:0] | 2 | Location of first SOP in the beat:
Note: If a new TLP is to
start in a new data beat (without remnant from the previous TLP)
then it should always start in byte lane 0
|
| 55:54 | is_sop1_ptr[1:0] | 2 | Location of second SOP in the beat:
|
| 57:56 | is_sop2_ptr[1:0] | Location of third SOP in the beat:
|
|
| 59:58 | is_sop3_ptr[1:0] | Location of fourth SOP in the beat:
|
|
| 63:60 | is_eop[3:0] | 4 | Indicates that a TLP is ending in this beat.
These outputs are set in the final beat of a TLP. When straddle is
enabled, the settings are as follows:
The 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. |
| 68:64 | is_eop0_ptr[4:0] | 5 | Offset of the last Dword of the first TLP ending in this beat. This output is valid when is_eop[0] is asserted. |
| 73:69 | is_eop1_ptr[4:0] | 5 | Offset of the last Dword of the second TLP ending in this beat. This output is valid when is_eop[1] is asserted. |
| 78:74 | is_eop2_ptr[4:0] | 5 | Offset of the last Dword of the third TLP ending in this beat. This output is valid when is_eop[2] is asserted. |
| 83:79 | is_eop3_ptr[4:0] | 5 | Offset of the last Dword of the fourth TLP ending in this beat. This output is valid when is_eop[3] is asserted. |
| 84 | 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 pcie(n)_s_axis_rq_tvalid is High. The core samples this signal only when pcie(n)_s_axis_rq_tready is High. Thus, once asserted, it should not be deasserted until pcie(n)_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). |
| 128:85 | reserved | 44 | These bits are reserved. |
| 256:129 | parity[127:0] | 128 | Odd parity for the 1024-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
pcie(n)_s_axis_rq_tdata. |
| 260:257 | pasid_valid[3:0] | 4 | Indicates PASID TLP 0,1,2,3 is valid based on the bits set. |
| 340:261 | pasid[79:0] | 80 | Every 20 bits indicates PASID TLP Prefix for TLP0,1,2,3 to the user design |
| 344:341 |
pasid_exe_req[3:0] |
4 | Indicates Execute Requested for TLP0,1,2,3. |
| 348:345 |
pasid_pmode_req[3:0] |
4 | Indicates Privileged Mode Requested for TLP0,1,2,3 to the user design. |
| 354:349 | 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(n)_cfg_status_rq_seq_num0
or pcie(n)_cfg_status_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 This input can be
hardwired to 0 when the user logic is not monitoring the |
| 360:355 | 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 pcie(n)_s_axis_rq_tvalid and pcie(n)_s_axis_rq_tready are both high. This input can be hardwired to 0 when the user logic is not monitoring the pcie(n)_cfg_status_rq_seq_num* outputs of the core. |
| 366:361 | seq_num2[5:0] | 6 | Sequence number for the third TLP starting in this beat. |
| 372:367 | seq_num3[5:0] | 6 | Sequence number for the fourth TLP starting in this beat. |