Sources of Additional Latency - 3.1 English

It is highly desirable to avoid throttling on the Monitor Interface, because it increases the total error mitigation latency:

• After an attempted error correction, but before exiting the Error Correction state (at which time the status_uncorrectable flag is updated), the controller issues a detection and correction report through the Monitor Interface. If the UART helper block transmit FIFO becomes full during this report generation, the controller dwells in this state until it has written the entire report into the UART helper block transmit FIFO. When this happens, the error correction latency increases.
• After classifying an error, but before exiting the Error Classification state (at which time the status_essential flag is updated), the controller issues a classification report through the Monitor Interface. If the UART helper block transmit FIFO becomes full during this report generation, the controller dwells in this state until it has written the entire report into the UART helper block transmit FIFO. When this happens, the error classification latency increases.

For helper blocks or peripherals where the potential bottleneck is a concern, it can be mitigated. This is accomplished by adjusting the transmit FIFO size to accommodate the longest burst of status messages that are anticipated so that the transmit FIFO never goes full during error mitigation.

If a transmit FIFO full condition does occur, the increase in the total error mitigation latency is roughly estimated as shown in the following equation.

In the previous equation , MessageLength – BufferDepth is in message bytes, and the Transmission Rate is in bytes per unit of time.

Performing error injection using Linear Frame Addressing also adds additional latency because the controller needs to first translate this address to a Physical Frame Address. The latency for this translation is also dependent on where the error occurred—the larger the address, the longer it takes to translate.