During the third step the master successfully rearbitrates for the bus and

During the third step the master successfully

This preview shows page 81 - 83 out of 344 pages.

During the third step, the master successfully rearbitrates for the bus and reissues the original request. The target decodes the request and gives the master the completion status (and data if a read request). At this point, the Delayed Completion is retired and the transaction has completed. The status returned to the master is exactly the same as the target obtained when it executed (completed) the Delayed Request (i.e., Master-Abort, Target-Abort, parity error, normal, Disconnect, etc.).
Image of page 81
PCI SPECIFICATIONS VOLUME 1 82 PCI-SIG PCI LOCAL BUS SPECIFICATION, REV. 3.0 3.3.3.3.2. Information Required to Complete a Delayed Transaction To complete a transaction using Delayed Transaction termination, a target must latch the following information: address command byte enables address and data parity, if the Parity Error Response bit (bit 6 of the command register) is set REQ64# (if a 64-bit transfer) For write transactions completed using Delayed Transaction termination, a target must also latch data from byte lanes for which the byte enable is asserted and may optionally latch data from byte lanes for which the byte enable is deasserted. Refer to Appendix F for requirements for a bridge to latch LOCK# when completing a Delayed Transaction. On a read transaction, the address and command are available during the address phase and the byte enables during the following clock. Byte enables for both read and write transactions are valid the entire data phase and are independent of IRDY# . On a write transaction, all information is valid at the same time as a read transaction, except for the actual data, which is valid only when IRDY# is asserted. Note: Write data is only valid when IRDY# is asserted. Byte enables are always valid for the entire data phase regardless of the state of IRDY# . The target differentiates between transactions (by the same or different masters) by comparing the current transaction with information latched previously (for both Delayed Request(s) and Delayed Completion(s)). During a read transaction, the target is not required to use byte enables as part of the comparison, if all bytes are returned independent of the asserted byte enables and the accessed location has no read side-effects (pre-fetchable). If the compare matches a Delayed Request (already enqueued), the target does not enqueue the request again but simply terminates the transaction with Retry indicating that the target is not yet ready to complete the request. If the compare matches a Delayed Completion, the target responds by signaling the status and providing the data if a read transaction. The master must repeat the transaction exactly as the original request, including write data in all byte lanes (whether the corresponding byte enables are asserted or not). Otherwise, the target will assume it is a new transaction. If the original transaction is never repeated, it will eventually be discarded when the Discard Timer expires (refer to Section 3.3.3.3.3). Two masters could request the exact same transaction and the target cannot and need not distinguish between them and will simply complete the access.
Image of page 82
Image of page 83

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture