Editing Peripheral Component Interconnect (section)

==PCI bus latency==
Soon after promulgation of the PCI specification, it was discovered that lengthy transactions by some devices, due to slow acknowledgments, long data bursts, or some combination, could cause [[buffer underrun]] or overrun in other devices.  Recommendations on the timing of individual phases in Revision 2.0 were made mandatory in revision 2.1:<ref name="changes21">{{Cite tech report |url=http://download.intel.com/design/chipsets/applnots/27301101.pdf |title=PCI Local Bus Specification: Revision 2.1 vs. Revision 2.0 |date=March 1997 |publisher=Intel Corporation |type=Application Note |id=AP-753 |archive-url=https://web.archive.org/web/20150430001953/http://download.intel.com/design/chipsets/applnots/27301101.pdf |archive-date=2015-04-30}}</ref>{{Rp|3}}

* A target must be able to complete the initial data phase (assert TRDY# and/or STOP#) within 16 cycles of the start of a transaction.
* An initiator must complete each data phase (assert IRDY#) within 8 cycles.

Additionally, as of revision 2.1, all initiators capable of bursting more than two data phases must implement a programmable latency timer.  The timer starts counting clock cycles when a transaction starts (initiator asserts FRAME#).  If the timer has expired ''and'' the arbiter has removed GNT#, then the initiator must terminate the transaction at the next legal opportunity.  This is usually the next data phase, but Memory Write and Invalidate transactions must continue to the end of the cache line.

===Delayed transactions===
Devices unable to meet those timing restrictions must use a combination of [[#Posted writes|posted writes]] (for memory writes) and delayed transactions (for other writes and all reads).  In a delayed transaction, the target records the transaction (including the write data) internally and aborts (asserts STOP# rather than TRDY#)  the first data phase.  The initiator ''must'' retry exactly the same transaction later.  In the interim, the target internally performs the transaction, and waits for the retried transaction.  When the retried transaction is seen, the buffered result is delivered.

A device may be the target of other transactions while completing one delayed transaction; it must remember the transaction type, address, byte selects and (if a write) data value, and only complete the correct transaction.

If the target has a limit on the number of delayed transactions that it can record internally (simple targets may impose a limit of 1), it will force those transactions to retry without recording them.  They will be dealt with when the current delayed transaction is completed.  If two initiators attempt the same transaction, a delayed transaction begun by one may have its result delivered to the other; this is harmless.

A target abandons a delayed transaction when a retry succeeds in delivering the buffered result, the bus is reset, or when 2<sup>15</sup>=32768 clock cycles (approximately 1&nbsp;ms) elapse without seeing a retry.  The latter should never happen in normal operation, but it prevents a [[deadlock (computer science)|deadlock]] of the whole bus if one initiator is reset or malfunctions.