P-Tile Avalon® Streaming Intel® FPGA IP for PCI Express* User Guide

ID 683059
Date 4/04/2024
Public
Document Table of Contents

4.4.2. Avalon® -ST RX Interface

The Application Layer receives data from the Transaction Layer of the PCI Express* IP core over the Avalon® -ST RX interface. The application must assert rx_st_ready_i before transfers can begin.

This interface supports two rx_st_sop_o signals and two rx_st_eop_o signals per cycle when the P-Tile IP is operating in a 1x16 configuration. It also does not follow a fixed latency between rx_st_ready_i and rx_st_valid_o.

The x16 core provides two segments with each one having 256 bits of data (rx_st_data_o[511:256] and rx_st_data_o[255:0]), 128 bits of header (rx_st_hdr_o[255:128] and rx_st_hdr_o[127:0]), and 32 bits of TLP prefix (rx_st_tlp_prfx_o[63:32] and rx_st_tlp_prfx_o[31:0]). If this core is configured in the 1x16 mode, both segments are used, so the data bus becomes a 512-bit bus rx_st_data_o[511:0]. The start of packet can appear in the upper segment or lower segment, as indicated by the rx_st_sop_o[1:0] signals.

Note: To achieve the expected performance in Gen4 x16 mode, the user application needs to take advantage of this segmented bus architecture. Otherwise, some performance reduction may occur.

If this core is configured in the 2x8 or 1x8 modes, only the lower segment is used. In this case, the data bus is a 256-bit bus rx_st_data_o[255:0].

Finally, if this core is configured in the 4x4 mode, only the lower segment is used and only the MSB 128 bits of data are valid. In this case, the data bus is a 128-bit bus rx_st_data_o[127:0].

The x8 core provides one segment with 256 bits of data, 128 bits of header and 32 bits of TLP prefix. If this core is configured in 4x4 mode, only the LSB 128 bits of data are used.

The x4 core provides one segment with 128 bits of data, 128 bits of header and 32 bits of TLP prefix.

Table 52.  Avalon-ST RX Interface
Signal Name Direction Description Clock Domain EP/RP/BP

x16 PCIe configuration: rx_st_data_o[511:0]

x8 PCIe configuration: rx_st_data_o[255:0]

x4 configuration: rx_st_data_o[127:0]

O

This is the Receive data bus. The Application Layer receives data from the Transaction Layer on this bus.

For TLPs with an end-of-packet cycle in the lower 256 bits, the 512-bit interface supports a start-of-packet cycle in the upper 256 bits.

coreclkout_hip EP/RP/BP

x16: rx_st_empty_o[5:0]

x8: rx_st_empty_o[2:0]

x4: rx_st_empty_o[1:0]

O

The rx_st_empty_o[5:0] bus is a split bus in x16 mode. rx_st_empty_o[5:3] correspond to the upper segment (rx_st_data_o[511:256]), and rx_st_empty_o[2:0] correspond to the lower segment (rx_st_data_o[255:0]).

The rx_st_empty_o signals specify the number of dwords that are ignored in each segment. The ignored dwords must be counted starting from the most significant bits of each segment.

The rx_st_empty_o signals are only valid when the rx_st_eop_o signals are asserted. These signals are not valid when the rx_st_eop_o signals are not asserted.

coreclkout_hip EP/RP/BP
rx_st_ready_i I

Indicates the Application Layer is ready to accept data.

The readyLatency is 27 cycles.

If rx_st_ready_i is deasserted by the Application Layer on cycle <n>, the Transaction Layer in the PCIe Hard IP continues to send traffic up to <n>+ readyLatency cycles after the deassertion of rx_st_ready_i.

Once rx_st_ready_i reasserts, rx_st_valid_o resumes data transfer within readyLatency cycles.

To achieve the best performance, the Application Layer must include a receive buffer large enough to avoid the deassertion of rx_st_ready_i.

coreclkout_hip EP/RP/BP

x16: rx_st_sop_o[1:0]

x8/x4: rx_st_sop_o

O

Signals the first cycle of the TLP when asserted in conjunction with the corresponding bit of rx_st_valid_o[1:0].

rx_st_sop_o[1]: When asserted, signals the start of a TLP on rx_st_data_o[511:256].

rx_st_sop_o[0]: When asserted, signals the start of a TLP on rx_st_data_o[255:0].

coreclkout_hip EP/RP/BP

x16: rx_st_eop_o[1:0]

x8/x4: rx_st_eop_o

O

The rx_st_eop_o[1:0] bus is a split bus in x16 mode.

When asserted, rx_st_eop_o[1] signals the end of a TLP on the upper segment (rx_st_data_o[511:256]).

When asserted, rx_st_eop_o[0] signals the end of a TLP on the lower segment (rx_st_data_o[255:0]).

The rx_st_eop_o signals indicate the last cycle of the TLP when asserted in conjunction with the corresponding bit of rx_st_valid_o[1:0].

coreclkout_hip EP/RP/BP

x16: rx_st_valid_o[1:0]

x8/x4: rx_st_valid_o

O

These signals qualify the rx_st_data_o signals going into the Application Layer.

coreclkout_hip EP/RP/BP

x16: rx_st_hdr_o[255:0]

x8/x4: rx_st_hdr_o[127:0]

O

This is the received header, which follows the TLP header format of the PCIe specifications.

coreclkout_hip EP/RP/BP

x16: rx_st_tlp_prfx_o[63:0]

x8/x4: rx_st_tlp_prfx_o[31:0]

O

This is the first TLP prefix received, which follows the TLP prefix format of the PCIe specifications. PASID is included.

These signals are valid when the corresponding rx_st_sop_o is asserted.

The TLP prefix uses a Big Endian implementation (i.e, the Fmt field is in bits [31:29] and the Type field is in bits [28:24]).

If no prefix is present for a given TLP, that dword (including the Fmt field) is all zeros.

coreclkout_hip EP/RP/BP

x16: rx_st_vf_active_o[1:0]

x8: rx_st_vf_active_o

x4: NA

O

When asserted, these signals indicate that the received TLP is targeting a virtual function. When these signals are deasserted, the received TLP is targeting a physical function and the rx_st_func_num signals indicate the function number.

These signals are valid when the corresponding rx_st_sop_o is asserted.

These signals are multiplexed with the rx_st_hdr_o signals in the x4 configuration.

These signals are valid in Endpoint mode only.

coreclkout_hip EP

x16: rx_st_func_num_o[5:0]

x8: rx_st_func_num_o[2:0]

x4: NA

O

Specify the target physical function number for the received TLP.

These signals are valid when the corresponding rx_st_sop_o is asserted.

These signals are multiplexed with the rx_st_hdr_o signals in the x4 configuration.

These signals are valid in Endpoint mode only.

coreclkout_hip EP

x16: rx_st_vf_num_o[21:0]

x8: rx_st_vf_num_o[10:0]

x4: NA

O

Specify the target VF number for the received TLP. The application uses this information for both request and completion TLPs. For a completion TLP, these bits specify the VF number of the requester for this completion TLP.

These signals are valid when rx_st_vf_active_o and the corresponding rx_st_sop_o are asserted.

These signals are multiplexed with the rx_st_hdr_o signals in the x4 configuration.

These signals are valid in Endpoint mode only.

coreclkout_hip EP

x16: rx_st_bar_range_o[5:0]

x8/x4: rx_st_bar_range_o[2:0]

O

Specify the BAR for the TLP being output.

For each BAR range, the following encodings are defined:
  • 000: Memory BAR 0
  • 001: Memory BAR 1
  • 010: Memory BAR 2
  • 011: Memory BAR 3
  • 100: Memory BAR 4
  • 101: Memory BAR 5
  • 110: I/O BAR
  • 111: Expansion ROM BAR

These outputs are valid when both rx_st_sop_o and rx_st_valid_o are asserted.

coreclkout_hip EP

x16: rx_st_tlp_abort_o[1:0]

x8/x4: rx_st_tlp_abort_o

O

This output signal is valid when rx_st_valid_o is asserted. It indicates to the application logic to drop a TLP because of an ECRC error. Application logic should not expect the TLP to be replayed.

By default, the PCIe Hard IP drops errored TLPs. However, while in TLP Bypass mode, errored TLPs are forwarded to the RX packet interface.

coreclkout_hip BP

x16: rx_st_data_par_o[63:0]

x8: rx_st_data_par_o[31:0]

x4: rx_st_data_par_o[15:0]

O If Enable Byte Parity Ports on Avalon-ST Interface parameter is enabled, application logic can use these signals to perform parity checking for rx_st_data_o. If a parity error is detected at the input of the Rx buffer inside the PCIe Hard IP, rx_par_err_o signal will be asserted. coreclkout_hip EP/RP/BP

x16: rx_st_hdr_par_o[31:0]

x8/x4: rx_st_hdr_par_o[15:0]

O If Enable Byte Parity Ports on Avalon-ST Interface parameter is enabled, application logic can use these signals to perform parity checking for rx_st_hdr_o. If a parity error is detected at the input of the Rx buffer inside the PCIe Hard IP, rx_par_err_o signal will be asserted. coreclkout_hip EP/RP/BP

x16: rx_st_tlp_prfx_par_o[7:0]

x8/x4: rx_st_tlp_prfx_par_o[3:0]

O If Enable Byte Parity Ports on Avalon-ST Interface parameter is enabled, application logic can use these signals to perform parity checking for rx_st_prfx_o. If a parity error is detected at the input of the Rx buffer inside the PCIe Hard IP, rx_par_err_o signal will be asserted. coreclkout_hip EP/RP/BP
rx_par_err_o O Asserted for a single cycle to indicate that a parity error was detected in a TLP at the input of the RX buffer. This error is logged as an uncorrectable internal error in the VSEC registers. If this error occurs, you must reset the Hard IP because parity errors can leave the Hard IP in an unknown state. coreclkout_hip EP/RP/BP
Figure 17.  Avalon® -ST RX Packet Interface in 1x16 Mode
Figure 18.  Avalon® -ST RX Packet Interface in 2x8 and 1x8 Modes
Note: In 2x8 mode, the pn prefix in the signal names is p0 and p1 for the two x8 ports. In 1x8 mode, the pn prefix in the signal names is p0 for the one x8 port.
Figure 19.  Avalon® -ST RX Packet Interface in 4x4 Mode
Note: In 4x4 mode, the pn prefix in the signal names is p0, p1, p2 and p3 for the four x4 ports.
Note: In the diagrams for the 1x16 mode or 2x8 and 1x8 modes, D0_0 represents a 256-bit block of data. However, in the diagram for the 4x4 mode, D0_0 represents a 128-bit block of data.