Equipment problems and channel noise can cause errors during Aurora 8B/10B channel operation. 8B/10B encoding allows the Aurora 8B/10B core to detect all single-bit errors and most multi-bit errors that occur in the channel and to assert soft_err on every cycle. The TX simplex cores do not include a soft_err port. All transmit data is assumed to be correct at transmission unless there is an equipment issue.
The core also monitors each transceiver for hardware errors such as buffer overflow/underflow and loss of lock and asserts the hard_err signal. RX-side hard errors in simplex cores are reported using the rx_hard_err signal. Catastrophic hardware errors can also manifest themselves as a burst of soft errors. The core uses the leaky bucket algorithm described in the Aurora 8B/10B Protocol Specification (SP002) [Ref 5] to detect large numbers of soft errors occurring in a short period of time, and asserts the hard_err or rx_hard_err signal.
Whenever a hard error is detected, the core automatically resets itself and attempts to re-initialize. This allows the channel to re-initialize and to be reestablished as soon as the hardware issue that caused the hard error is resolved. Soft errors do not lead to a reset unless enough of them occur in a short period of time.
Aurora 8B/10B cores with the AXI4-Stream data interface can also detect errors in Aurora 8B/10B frames and assert the frame_err signal. Frame errors can be frames with no data, consecutive Start of Frame symbols, and consecutive End of Frame symbols. This signal is not available with simplex TX cores. When available, this signal is usually asserted close to a soft_err assertion, with soft errors being the main cause of frame errors.
Table: Error Signals in Cores summarizes the error conditions Aurora 8B/10B cores can detect and the error signals used to alert the user application.
Table 2-13: Error Signals in Cores
|
Signal
|
Description
|
TX
|
RX
|
|
hard_err
|
TX Overflow/Underflow: The elastic buffer for TX data overflows or underflows. This can occur when the user clock and the reference clock sources are not running at the same frequency.
|
x
|
|
|
RX Overflow/Underflow: The elastic buffer for RX data overflows or underflows. This can occur when the clock source frequencies for the two channel partners are not within ± 100 ppm.
|
|
x
|
|
Bad Control Character: The protocol engine attempts to send a bad control character. This is an indication of design corruption or catastrophic failure.
|
x
|
|
|
Soft Errors: There are too many soft errors within a short period of time. The Aurora 8B/10B protocol defines a leaky bucket algorithm for determining the acceptable number of soft errors within a given time period. When this number is exceeded, the physical connection might be too poor for communication using the current voltage swing and pre-emphasis settings.
|
|
x
|
|
soft_err
|
Invalid Code: The 10-bit code received from the channel partner was not a valid code in the 8B/10B table. This usually means a bit was corrupted in transit, causing a good code to become unrecognizable. Typically, this also results in a frame error or corruption of the current channel frame.
|
|
x
|
|
Disparity Error: The 10-bit code received from the channel partner did not have the correct disparity. This error is also usually caused by corruption of a good code in transit, and can result in a frame error or bad data if it occurs while a frame is being sent.
|
|
x
|
|
No Data in Frame: A channel frame is received with no data.
|
|
x
|
|
frame_err
|
Truncated Frame: A channel frame is started without ending the previous channel frame, or a channel frame is ended without being started.
|
x
|
|
|
Invalid Control Character: The protocol engine receives a control character that it does not recognize.
|
|
x
|
|
Invalid UFC Message Length: A UFC message is received with an invalid length.
|
|
x
|