The retry protocol is used when the target does not yet have the data requested by the initiator.

The drawback of this approach is that the initiator will keep retrying every 2 clock cycles until the request succeeds. If the target continues to be unready, this repeated retrying can reduce system performance.

Procedure

1. Master starts a transaction

   • Example: North Bridge (master) wants to read data from the Ethernet device (target).

2. Target claims the cycle but isn’t ready

   • Ethernet device says: “I see your request, but I don’t have the data yet.”

3. Two options for the target:

   • (a) Insert wait states → if just a few clock cycles are needed.
   • (b) Retry (STOP#) → if more than 16 clocks would be needed.

4. What Retry (STOP#) does:

   • Tells the master: “End this attempt, come back later.”
   • The master stops the cycle immediately (without data transfer).
   • Prevents the PCI bus from being “hogged” with long wait states.

5. Master after retry:

   • Waits at least 2 clocks.
   • Goes back to arbitration to request the bus again.
   • Retries the same transaction.

6. Bus efficiency:

   • While the master is waiting, the arbiter can give the bus to other devices.
   • When the retried master gets the bus back, hopefully the target is ready this time.

7. If still not ready:

   • Target retries again.
   • This repeats until the data can finally be transferred.