4.4.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.
|Signal Name||Direction||Description||EP/RP/BP||Clock Domain|
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 and/or for the data crossing between the R-Tile Hard IP and the FPGA Core.
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.
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:
: tx_parity_err at the front end of the datapath inside the Hard IP.
: tx_parity_err at the back end of the datapath inside the Hard IP.
|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|
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
This error bus carries the following information:
|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?