Response Agent Responsibilities - Intel Pentium Pro Family Developer's Manual

BUS TRANSACTIONS AND OPERATIONS
For every transaction, only one agent is allowed to assert DEFER#. Normally it is the responsi-
bility of the agent addressed by the transaction. When the addressed agent always guarantees in-
order completion, the responsibility can be given to a unique third party agent who can assert
DEFER# on behalf of the addressed agent. Both agents must then agree on how to complete the
transaction and which agent will drive the response.
A deferred or retry response removes the transaction from the In-order Queue. On a retry re-
sponse, it is the responsibility of the requesting agent to initiate the transaction repeatedly until
the transaction either receives a deferred or in-order completion response. On a deferred re-
sponse, the response agent must latch the Deferred ID, DID[7:0]# issued during the Request
Phase. After the response agent completes the original request, it must issue a matching De-
ferred Reply Bus Transaction. The Deferred Reply transaction's Request Phase must begin at
least one clock after the Response Phase for the original transaction. The Deferred ID, available
during the original transaction's Request Phase, is used as the address in the Deferred Reply
Transaction's Request Phase.
A Deferred ID contains eight bits, divided into two four-bit fields. The Deferred ID is transferred
on pins Ab[23:16]# (signals DID[7:0]#) in the second clock of the original transaction's Request
Phase. Ab[23:20]# contain the request agent ID, which is unique for every agent. Ab[19:16]#
contains a request ID, assigned by the request agent based on its internal queue (typically a
queue index). Up to sixteen different agents can allow deferred responses. Up to sixteen deferred
responses can be pending for each of the sixteen agents. An agent that supports more than six-
teen outstanding deferred requests can use multiple agent IDs. The Pentium Pro processor limits
the number of outstanding deferred transactions to 4.
The deferred response agent uses the Deferred Reply Transaction phase to transfer completion
status of the deferred transaction. The Deferred ID is driven on address Aa[23:16]# during the
Deferred Reply Transaction's Request Phase. The final cache state after completion of the De-
ferred Reply for a Read Line Transaction is indicated by the HIT# signal. For a Deferred Reply
resulting from a Memory Invalidate Transaction which hit a modified line on another bus, the
deferring agent must echo the HITM# in the Snoop Result Phase of the Deferred Reply in order
to return unexpected data (the Snoop Result Phase indicates all changes in the length of data re-
turned). During the response phase, the appropriate response is driven to indicate completion
status of the transaction.
Agents can use the deferred response mechanism when an operation has significantly greater la-
tency than the normal in-order response. The deferred response mechanism can be used to im-
plement non-blocking bridge components between the Pentium Pro processor bus and a system
bus to maintain concurrency with guaranteed forward progress.
Deferred transactions enter the In-order Queue in the same way as all other transactions. ADS#
for a deferred reply may be asserted no sooner than one cycle after RS[2:0]# is asserted for the
original transactions that has been deferred.
5.3.3.1.

RESPONSE AGENT RESPONSIBILITIES

A response agent willing to give a deferred response must maintain an internal deferred reply
pool with up to n entries. At the time it wishes to give a deferred response, the response agent
must assign an entry for the transaction in the deferred reply pool and store the Deferred ID
5-17