Symmetric Cryptographic Intel FPGA Hard IP User Guide

ID 714305
Date 10/31/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.7. Error Reporting

The Symmetric Cryptographic IP core can report various types of errors: ICV errors, client errors, AES/SM4 Inline Cryptographic Accelerator errors, bridge-specific errors, and any other fatal internal errors including a FIFO overflow errors.
The IP uses three mechanisms to report errors:
  1. tuser.err_code signal: Used for errors associated with a profile, channel, or data cycle.

    The error propagates out with the AXI-ST data cycle. The error is valid when AXI-ST valid signal is set to 1 and the tuser_error_status signal is set to 1. The signal can only forward a single error code in the event of multiple simultaneous errors. You can include or exclude errors through the static configuration registers, such as err_code_ctrl1, err_code_ctrl2, and err_code_int signals.

  2. tuser.internal_error signal: Used for errors that cannot be associated with a profile, channel, or data cycle. Also, used for errors that can leave the datapath unreliable.

    This signal asserts independently from the AXI-ST interface. The error is a pulse signal that is a bit-synchronized over to the fabric clock domain. You can include or exclude errors through the static pinerr_ctrl register.

  3. Error Status Logs via different types of files:
    • First Error Log (ferr_log): Monitors the internal errors and packet errors reported on AXI-ST datapath and captures the first error to assert. Each error can be included or excluded from this by setting the Static Configuration registers interr_ctrl, pacerr_ctrl1, pacerr_ctrl2.
    • Internal Error Log (interr_log): Contains the internal errors reported by various submodules within the datapath.
    • Packet Error Log 1 (pacerr_log1): Contains errors for generic GCM and generic XTS profiles.
    • Packet Error Log 2 (pacerr_log2): Contains errors for MACsec and IPsec profiles.

Bridge Clearing Mechanism

The IP supports the following clearing mechanisms:
Table 20.  Bridge Clearing Signals
Signal Name Description
subsystem_cold_reset_n Global reset
tuser.error_clear Profile-based in-band reset sent with tvalid signal and a profile ID. Clears the bridge specified by the profile ID.

This signal does not clear the AES/SM4 Inline Cryptographic Accelerator.

ctrl_primary.clear_macsec_bridge_states

ctrl_primary.clear_ipsec_bridge_states

ctrl_primary.clear_gcm_bridge_states

ctrl_primary.clear_xts_bridge_states

Profile-based resets used as a backup feature.

These signals do not clear the AES/SM4 Inline Cryptographic Accelerator.