R-tile Avalon® Streaming Intel® FPGA IP for PCI Express* User Guide

ID 683501
Date 6/20/2022
Public

A newer version of this document is available. Customers should click here to go to the newest version.

Document Table of Contents

4.3.5. Error Interface

This is an optional interface that allows the Application Layer to report errors to the IP core and vice versa. Specifically, the Application Layer can report the different types of errors defined by the app_error_info_i signal to the IP. For Advanced Error Reporting (AER), the Application Layer can provide the information to log the TLP header and the error log request via the app_err_* interface.

Note: The AER capability for Physical Functions (PFs) is enabled by default. There is no AER implementation for Virtual Functions (VFs). Use the VF Error Flag Interface instead of AER when using VFs.
Table 64.  Error Interface Signals
Signal Name Direction Description EP/RP/BP Clock Domain
pX_serr_out_o Output

Indicates if a system error is detected.

EP mode: This signal is asserted when the R-tile PCIe Hard IP sends a message of a correctable/non-fatal/fatal error.

RP mode: A one-clock-cycle pulse on this signal indicates if any device in the hierarchy reports any of the following errors and the associated enable bit is set in the Root Port Control register: ERR_COR, ERR_FATAL, ERR_NONFATAL. This signal is also asserted when an internal error is detected. The source of the error will be logged in the Root Port Error Status registers in the Port Configuration and Status registers.

BP mode: The transaction layer or data link layer errors detected by the Hard IP core trigger this signal. Detailed information are logged in the Bypass Mode Error Status registers in the Port Configuration and Status registers.

All modes: This signal is asserted to indicate if a parity error was detected for the received data or for the data crossing between the R-Tile Hard IP and the FPGA Core.

For Tx:

If the GUI option Enable byte parity ports on Avalon-ST interface is enabled, there will be a parity check using the parity bits provided on the ports pX_tx_stN_data_par_i, pX_tx_stN_hdr_par_i and pX_tx_stN_prefix_par_i.

For Rx:

There will be a parity check internal to the R-Tile for the data being received.

Additionally, If the GUI option Enable byte parity ports on Avalon-ST interface is enabled, parity bits will be provided on the ports pX_rx_stN_data_par_o, pX_rx_stN_hdr_par_o and pX_rx_stN_prefix_par_o, to allow an additional parity check in the Application logic to verify data integrity after crossing the EMIB.

In case of an error, you can use the Hard IP Reconfiguration interface to read address 0x1319 for additional information on the type of error:

[0]: rx_correctable_err

[1]: rx_uncorrectable_err

[2]: rx_parity_err

[3]: tx_correctable_err

[4]: tx_uncorrectable_err

[5]: tx_parity_err at the front end of the datapath inside the Hard IP.

[6]: tx_parity_err at the back end of the datapath inside the Hard IP.

EP/RP/BP slow_clk
pX_app_err_valid_i Input A one-cycle pulse on this signal indicates that the data on app_err_info_i, app_err_hdr_i, and app_err_func_num_i are valid in that cycle and app_err_hdr_i will be valid during the following four cycles. EP/RP slow_clk
pX_app_err_hdr_i[31:0] Input

This bus contains the header and TLP prefix information for the error TLP.

The 128-bit header and 32-bit TLP prefix are sent to the Hard IP over five cycles (32 bits of information are sent in each clock cycle).

Cycle 1 : header[31:0]

Cycle 2 : header[63:32]

Cycle 3 : header[95:64]

Cycle 4 : header[127:96]

Cycle 5 : TLP prefix

EP/RP slow_clk
pX_app_err_info_i[13:0] Input
This error bus carries the following information:
  • [0]: Malformed TLP
  • [1]: Receiver overflow
  • [2]: Unexpected completion
  • [3]: Completer abort
  • [4]: Completion timeout
  • [5]: Unsupported request
  • [6]: Poisoned TLP received
  • [7]: AtomicOp egress blocked
  • [8]: Uncorrectable internal error
  • [9]: Correctable internal error
  • [10]: Advisory error
  • [11]: TLP prefix blocked
  • [12]: ACS violation
  • [13]: ECRC check failed
EP/RP slow_clk

x16/x8: pX_app_err_func_num_i[2:0]

x4: NA

Input This bus contains the function number for the function that asserts the error valid signal. EP/RP slow_clk
pX_app_err_ready_o Output When deasserted, this signal indicates the endpoint may be in the process of servicing another message, and unable to service this Master for back-to-back user input. EP/RP slow_clk

Did you find the information on this page useful?

Characters remaining:

Feedback Message