Non-Posted Write Data Parity Errors

During a write transaction, the master sources the write data and must assert IRDY# when the data is valid independent of the response by the target. Therefore, a data parity error can occur during any attempt (initial or subsequent) by the originating master that is terminated with Retry.

A data parity error can also occur when a non-posted write transaction is completed on the destination bus by the bridge. In addition, it is possible for a data parity error to be constant (i.e., the same error occurs each time the master repeats the transaction) or transient (i.e., the error

occurs on some but not other repetitions of the transaction by the master). The error handling methods for a bridge are designed to detect and report both constant and transient data parity errors during non-posted writes and to prevent transient data parity errors from causing a live-lock or deadlive-lock. The following sections describe the error handling methods used by a bridge for each of these cases.

6.2.3.1. Master Request Error

If the bridge detects a data parity error when responding as a target on its primary interface to a write transaction that would otherwise have been handled as a Delayed Transaction, the bridge must do the following:

• Complete the data phase in which the error occurred by asserting TRDY#. If the master is attempting a burst, the bridge must also assert STOP#.

• Report the error to the master by asserting PERR# (if enabled to do so by the Parity Error Response bit in the Command register).

• Set the Detected Parity Error bit in the Status register.

• Discard the transaction. No Delayed Write Request is enqueued and no Delayed Write Completion is retired.

If the bridge detects a data parity error when responding as a target on its secondary interface to a write transaction that would otherwise have been handled as a Delayed Transaction, the bridge must do the following:

• Complete the data phase in which the error occurred by asserting TRDY#. If the master is attempting a burst, the bridge must also assert STOP#.

• Report the error to the master by asserting PERR# (if enabled to do so by the Parity Error Response bit in the Bridge Control register).

• Set the Detected Parity Error bit in the Secondary Status register.

• Discard the transaction. No Delayed Write Request is enqueued and no Delayed Write Completion is retired.

When parity error response is enabled, the bridge will only enqueue a Delayed Write Request when a data parity error is not detected during the master request.

6.2.3.2. Target Completion Error

The bridge forwards a Delayed Write Request to the destination bus only if no error occurred during the master request. However, a data parity error may occur when the transaction is completed on the destination bus. In this case, the error is forwarded back to the originating master during the Master Completion phase of the transaction.

When a Delayed Write Request is forwarded upstream by the bridge to its primary interface, the target of the transaction asserts PERR# if it detects a data parity error (and is enabled to report parity errors). If PERR# is asserted by the target, then the bridge must:

• set the Master Data Parity Error bit in the Status register

• record the occurrence of the error in the corresponding Delayed Write Completion (produced by completion of the Delayed Write Request)

When the Delayed Write Completion is returned to the originating master on the secondary interface of the bridge, the bridge must reflect the occurrence of the error from the destination bus to the master by asserting PERR# (if enabled). The Detected Parity Error bit in the Secondary Status register is not set.

When a Delayed Write Request is forwarded downstream by the bridge to its secondary interface, the target of the transaction asserts PERR# if it detects a data parity error (and is enabled to report parity errors). If PERR# is asserted by the target, then the bridge must:

• set the Master Data Parity Error bit in the Secondary Status register

• record the occurrence of the error in the corresponding Delayed Write Completion (produced by completion of the Delayed Write Request)

When the Delayed Write Completion is returned to the originating master on the primary interface of the bridge, the bridge must reflect the occurrence of the error from the destination bus to the master by asserting PERR# (if enabled). The Detected Parity Error bit in the Status register is not set.

6.2.3.3. Master Completion Error

If the bridge enqueues a Delayed Write Request and later detects a data parity error during a subsequent repetition of the transaction by the originating master, the bridge terminates the repeated transaction as if it were a new transaction as described in Section 6.2.3.1. The bridge does not retire any Delayed Write Completions even if the transaction appears to match one previously enqueued (it is impossible to determine whether the transaction really matches a previously enqueued one since an error is present).

If a constant data parity error is present on all subsequent reattempts of a previously enqueued Delayed Write Request, then the bridge will eventually have an orphan Delayed Write

Completion (as a result of the initial Delayed Request). The orphan completion is discarded when the discard timer expires (refer to Sections 5.3. and 6.5.). While waiting for the discard timer to expire, the bridge may not be able to accept a new Delayed Transaction since it is not required to handle multiple Delayed Transactions at the same time. However, since this condition is temporary, a deadlock cannot occur. While in this condition, the bridge is required to complete transactions that use Memory Write and Memory Write and Invalidate transactions (refer to Sections 5.5. and 5.6.3.).