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

ID 683059
Date 10/02/2023
Public

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

Document Table of Contents

4.7. Error Interface

This is an optional interface in the Intel P-Tile Avalon® -ST IP for PCI Express 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 Intel P-Tile Avalon® -ST IP for PCI Express enables the AER capability for Physical Functions (PFs) by default. There is no AER implementation for Virtual Functions (VFs). Use the VF Error Flag Interface instead of AER when using VFs.
Table 67.  Error Interface Signals
Signal Name Direction Description Clock Domain EP/RP/BP
serr_out_o O

Indicates system error is detected.

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 Control register: ERR_COR, ERR_FATAL, ERR_NONFATAL. 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.

EP mode:

Asserted when the P-Tile PCIe Hard IP sends a message of correctable/non-fatal/fatal error.

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.
coreclkout_hip EP/RP/BP
hip_enter_err_mode_o O Asserted when the Hard IP enters the error mode. This usually happens when the Hard IP detects an uncorrectable internal error. Upon seeing the assertion of this signal, you should discard all the TLPs received. coreclkout_hip EP/RP/BP
app_err_valid_i I A one-cycle pulse on this signal indicates that the data on app_err_info, app_err_hdr, and app_err_func_num are valid in that cycle and app_err_hdr_i will be valid during the following four cycles. coreclkout_hip EP/RP
app_err_hdr_i[31:0] I

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

coreclkout_hip EP/RP
app_err_info_i[12:0] I 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
coreclkout_hip EP/RP

x16/x8: app_err_func_num_i[2:0]

x4: NA

I This bus contains the function number for the function that asserts the error valid signal. coreclkout_hip EP