Five Example Scenarios
A Transaction that Doesn't Transfer Data
Figure 51-1 on page 1249 illustrates a transaction that doesn't require a data transfer. This would include:
The Special transaction.
A transaction that receives a retry response.
A transaction that receives a hard failure response.
A read transaction that receives a deferred response (the data will be transferred at a later time in a subsequent Deferred Reply transaction) and doesn't hit on a modified line (the case where it hits a modified line is described in “A Read that Hits a Modified Line” on page 1262).
A Memory Code or Data Read or a Memory Read and Invalidate for 0 bytes (that does not hit on a modified line).
In these cases, the Data Bus is not used by the Request Agent (because it's not a write), nor by the Response Agent (because no data is being read), nor by any of the snoopers (because it doesn't hit a modified line).
The Response Phase is entered immediately upon delivery of the transaction's snoop result (at the start of BCLK cycle 4). However, the target of this transaction must ensure that it doesn't drive its response until both of the following conditions have been met:
The Snoop Phase for this transaction must have completed. A Response Agent must detect the snoop result (see the start of BCLK cycle 4) before it can determine what its response will be.
The Response Agent observed the target of the previous transaction deliver its response and then idle the response signals. In order to allow signal settling time, it must not drive its response until at least two clocks after the response from the previous Response Agent is sampled. This allows one clock for the previous target to backoff its drivers from RS[2:0]# and one clock for the lines to settle before the target of the current transaction starts to turn on its RS drivers. Remember that it is permissible for the target of a transaction to delay the delivery of its response (by keeping RS[2:0]# deasserted) until is ready to deliver its response. It drives its response (see Table 51-1 on page 1244) for one clock and then releases the RS[2:0]# signals (which return to the Idle state).
Assume that the target of the current transaction isn't paying attention (i.e., it's not properly tracking all currently outstanding transactions) and drives its response to its Request Agent before the target of the previously-issued transaction drives its response to the Request Agent that addressed it. The Request Agent that issued the earlier transaction would receive the response from the wrong target for a transaction that it didn't issue. This would absolutely confuse everyone involved. Another possibility is that both targets would simultaneously drive the RS signals, resulting in a wire-ORed (i.e., bogus) result.
The appropriate response for a transaction that doesn't require a data transfer is the no data response (see clock 8).
A Read that Doesn't Hit a Modified Line and is Not Deferred
The Basics
Figure 51-2 on page 1250 illustrates a read for two qwords (16 bytes) that doesn't hit a modified line and isn't deferred:
The Response Agent will take ownership of the Data Bus and transfer the requested data to the Request Agent.
The Response Agent will supply the Normal Data response at the same time that it takes ownership of the Data Bus.
None of the Snoop Agents has a copy of the line in the modified state and therefore a snooper will not be writing data to memory.
Figure 51-2. Example 2: Read that Doesn't Hit a Modified Line and Isn't Deferred
A Detailed Description
On a read transaction, the Response Agent delivers the Normal Data response (see BCLK cycle 5) if it intends to transfer the requested data. At the same time that it drives the response, it takes ownership of the Data Bus (asserts DBSY#) in preparation for driving the requested read data back to the Request Agent. Before delivering its response, the Response Agent must be sure that all of the following conditions are met:
The Response Agent doesn't deliver its response unless the snoop result was detected at least one BCLK cycle earlier (see the start of BCLK cycle 4). It needs the snoop result to determine what its response will be.
The Response Agent doesn't deliver its response until the previous transaction's Response Agent has issued its response and the RS lines have settled (we must not confuse the previous transaction's Request Agent by giving it the response to the wrong transaction; in addition, the Response Agent must not start driving the RS lines until they have quit ringing). At the earliest, the response for the current transaction can be driven three BCLK cycles after the previous response was driven—this allows one clock for the previous response to be driven, one clock for the Response Agent to back off its drivers, and one clock for the RS lines to settle.
If the previous transaction requires a data transfer, the current transaction's Response Agent must not deliver its response until the previous transaction's Request or Response Agent (whichever is using the Data Bus) has completed its data transfer and yielded ownership of the Data Bus (i.e., it has deasserted DBSY#; DBSY# is sampled deasserted at the start of BCLK cycle 4).
In Figure 51-2 on page 1250, the Response Agent takes ownership of the Data Bus by asserting DBSY# in BCLK cycle 5. When it's ready to drive the first data item (up to eight bytes of data), it asserts DRDY# and drives the data as well as the Data Strobes (not shown). If it's not ready to drive the data, it asserts DBSY#, but holds off on the assertion of DRDY# until the BCLK cycle wherein it begins driving the data.
The Response Agent asserts DBSY# and DRDY# and drives the first qword onto the Data Bus in BCLK cycle 5. During BCLK cycle 5, the data is strobed into the Request Agent's input receiver by the data strobes (not shown).
The Request Agent samples DRDY# asserted at the start of BCLK cycle 6, qualifying the data it received on D[63:0]# in the previous BCLK cycle as valid. In addition, the Request Agent also samples RS[2:0]# and receives the Normal Data response (the appropriate response for a read).
Finally, the Response Agent deasserts DBSY# and DRDY# and ceases driving the response onto RS[2:0]#. This concludes the transaction.
How Does the Response Agent Know the Transfer Length?
The Request Agent delivers the transfer length in the LEN field of Packet B during the Request Phase (refer to “The Contents of Request Packet B” on page 1219). The possible lengths are:
One qword or a subset thereof (the Byte Enables in Packet B indicate the addressed bytes within the target qword).
Two full qwords (16 bytes) in toggle mode transfer order.
Four full qwords (32 bytes) in toggle mode transfer order.
Eight full qwords (64 bytes) in toggle mode transfer order.
The Earliest Deassertion of DBSY#
The earliest point at which DBSY# can be deasserted is in the BCLK cycle wherein the final data item is transferred (BCLK cycle 5 in Figure 51-2 on page 1250). There's no danger of the next Data Bus user taking ownership too soon because the next owner won't sample DBSY# deasserted until the start of the next BCLK cycle and cannot take ownership until one BCLK cycle after that. This provides the current Data Bus owner with one BCLK cycle to drive the final data item and one BCLK cycle to back off from the Data Bus before the next owner can assert DBSY# and take ownership of the Data Bus.
Special Case—Single BCLK, 0-Wait State Transfer
Figure 51-2 on page 1250 is a case where all of the data is transferred in a single BCLK cycle. When a transaction's data transfer can be completed in one BCLK cycle and the agent sourcing the data can immediately supply the data when it gains data bus ownership, the agent does not have to assert DBSY#. It just asserts DRDY# immediately upon acquiring Data Bus ownership and drives out the data (and the data strobes). It should be noted that although Figure 51-2 on page 1250 shows DBSY# asserted for a single BCLK cycle, it needn't be (but it doesn't hurt anything, either).
There is no danger of an ownership collision on the Data Bus. Whether the next transaction is a read or a write, the agent that will source data in that transaction cannot take ownership of the Data Bus until the response for this transaction has been seen.
A Write that Doesn't Hit a Modified Line and Isn't Deferred
Introduction
Figure 51-3 on page 1253 illustrates two back-to-back write transactions:
A 2-qword (16 byte) write that doesn't hit on a modified line and isn't deferred.
A 4-qword (32-byte) write that doesn't hit on a modified line and isn't deferred.
Figure 51-3. Example 3a: Write that Doesn't Hit a Modified Line and Isn't Deferred
In both cases, the Request Agent writes data to the Response Agent in the Data Phase of the transaction. The following discussion focuses on both transactions.
Transaction 1's Response
Refer to Figure 51-3 on page 1253. The Request Agent that issues transaction 1 samples a valid snoop result (a snoop miss) at the start of BCLK cycle 4. This completes transaction 1's Snoop Phase and starts its Response Phase.
Transaction 1's Target Is Ready to Accept Write Data
Refer to Figure 51-4 on page 1254. The Response Agent of transaction 1 asserts TRDY# at the start of BCLK cycle 4 to indicate that it is ready to accept the 16 bytes of write data.
Figure 51-4. Example 3b: Write that Doesn't Hit a Modified Line and Isn't Deferred
When a Request Agent initiates a write transaction, the Response Agent cannot assert TRDY# until all of the following conditions have been met:
The Response Agent must have a buffer available that is big enough to accept up to 32 bytes of data in a single BCK cycle.
TRDY# cannot be asserted sooner than three BCLK cycles after ADS# is asserted.
The response for the previous transaction must have been driven at least one BCLK earlier (because the latest that TRDY# can be deasserted is when the response is driven).
The Response Agent “knows” that the response was driven for the previous transaction in one two ways:
If the Response Agent was not the target of the previous transaction, the current transaction's Response Agent must have sampled the response issued by the previous transaction's Response Agent.
If the same agent is targeted in the previous and the current transactions, it knows when it drove its response.
Transaction 1's Request Agent Gets the Go-Ahead
As shown in Figure 51-5 on page 1255, transaction 1's Request Agent samples TRDY# and DBSY# for the first time at the start of BCLK cycle 5:
The asserted state of TRDY# indicates that the Response Agent is ready to accept the write data.
The deasserted state of DBSY# indicates that the Data Bus is no longer in use by the agents that were involved in the previous transaction.
Figure 51-5. Example 3c: Write that Doesn't Hit a Modified Line and Isn't Deferred
As a result, the Request Agent will take ownership of the Data Bus one BCLK cycle later in order to source the write data to the target (i.e., the Response Agent).
Condition that Permits 1 BCLK TRDY# Assertion
As shown in Figure 51-6 on page 1256, transaction 1's Response Agent is permitted to deassert TRDY# after a single-BCLK assertion if it sampled DBSY# deasserted at the start of the BCLK cycle in which it asserted TRDY#. If DBSY# is sampled deasserted at that point, the Response Agent knows that the Request Agent will see TRDY# asserted and DBSY# deasserted at the start of the next BCLK cycle (and that tells the Request Agent that it can take ownership of the Data Bus one BCLK cycle later).
Figure 51-6. Example 3d: Write that Doesn't Hit a Modified Line and Isn't Deferred
Transaction 1's Request Agent Takes Ownership of the Data Bus
Refer to Figure 51-7 on page 1257. As a result of sampling TRDY# asserted and DBSY# deasserted one BCLK cycle earlier, transaction 1's Request Agent takes ownership of the Data Bus at the start of BCLK cycle 6:
It asserts DBSY# to take ownership of the Data Bus.
It asserts DRDY# to indicate that it will drive valid data in this BCLK cycle.
This transaction is a 2 qword write, so it drives out the 2 qwords (in toggle mode transfer order).
It drives out the Data Bus Inversion signal (DBI[3:0]#) settings for the two qwords (DBI[3:0]# are not shown).
It also drives the Data Strobes necessary to strobe the data into the Response Agent's input receiver (the strobes are not shown).
Figure 51-7. Example 3e: Write that Doesn't Hit a Modified Line and Isn't Deferred
Transaction 1's Response Agent Drives Its Response
Refer to Figure 51-8 on page 1258. Transaction 1's Response Agent can drive its response when the following conditions have been met:
It has been at least one BCLK cycle since the snoop result for this transaction was detected.
At least three BCLK cycles have elapsed since the response for the previous transaction was driven.
If this is a write (and it is), the conditions for TRDY# deassertion were met at least one BCLK cycle earlier.
If there was a hit on a modified line (there wasn't), TRDY# must have been sampled asserted and DBSY# deasserted at least one BCLK cycle earlier.
If it's a read (it's not), DBSY# must have been sampled deasserted at least one BCLK cycle earlier.
Figure 51-8. Example 3f: Write that Doesn't Hit a Modified Line and Isn't Deferred
If TRDY# had not already been deasserted (at the start of BCLK cycle 5), it must be deasserted in the BCLK when the response is driven.
Transaction 1's Completion
Refer to Figure 51-9 on page 1259. At the start of BCLK cycle 7:
The transaction 1 Response Agent samples DBSY# asserted, indicating that the Request Agent has taken ownership of the Data Bus.
The transaction 1 Response Agent samples DRDY# asserted, indicating that valid data was delivered during the previous BCLK cycle. Since all of the write data was delivered, this ends the Data Phase.
The transaction 1 Request Agent samples RS[2:0]# and detects the No Data response. This ends the Response Phase.
Figure 51-9. Example 3g: Write that Doesn't Hit a Modified Line and Isn't Deferred
Transaction 1 has been completed.
Transaction 2's Description
Figure 51-10 on page 1261 describes transaction 2:
The Request Agent receives a valid snoop result (it's a miss) at the start of BCLK cycle 6. This completes the Snoop Phase and starts the Response Phase.
The Response Agent asserts TRDY# at the start of BCLK cycle 7.
TRDY# cannot be deasserted one BCLK cycle later, however, because the Response Agent sampled DBSY# asserted when it started asserting TRDY#.
The Request Agent samples TRDY# asserted and DBSY# deasserted at the start of BCLK cycle 8, giving it permission to take ownership of the Data Bus one BCLK cycle later.
The Response Agent deasserts TRDY# at the start of BCLK cycle 9 (because it knows that the Request Agent detected TRDY# asserted and DBSY# deasserted at the start of BCLK cycle 8).
The Request Agent takes ownership of the Data Bus at the start of BCLK cycle 9:
- It asserts DBSY#, indicating that the Data Bus is in use.
- It asserts DRDY#, indicating that it will drive valid write data in this BCLK cycle.
- It drives four qwords (32 bytes) of data.
- It drives the Data Bus Inversion signals (not shown) associated with the four Data Bus signal groups.
- It drives the data strobes (not shown) that the Response Agent uses to latch the write data into its input receiver.
The Response Agent drives its response (the No Data response) at the start of BCLK cycle 9.
The Request Agent samples a valid response at the start of BCLK cycle 10, ending the Response Phase.
The Response Agent samples DRDY# asserted, indicating that valid data was delivered to it during the previous BCLK cycle. This completes the Data Phase and the transaction.
At the start of BCLK cycle 10, the Request Agent deasserts DBSY# and DRDY#.
At the start of BCLK cycle 10, the Response Agent deasserts RS[2:0]#.
Figure 51-10. Example 3h: Write that Doesn't Hit a Modified Line and Isn't Deferred
A Hard Failure Response
If the Request Agent receives a hard failure response in the Response Phase, it may have already accepted some write data from the Request Agent. If it has, the Response Agent discards the data. In other words, it is important that data written to a Response Agent should initially be accepted into a buffer and only written to the target memory or IO location(s) if there is not a hard failure response.
The Snoop Agents Change the State of the Line from E to I or S to I
If any Snoop Agent had a hit on a line in the E or S state, it changes it to the I state (because it cannot snarf data being written to memory by another Request Agent).
A Read that Hits a Modified Line
Figure 51-11 on page 1263 illustrates a memory read that hits on a modified line. Refer to this figure during the following discussion. The read could be for any amount of data up to a full line.
The Basics
The Request Agent starts a read transaction to read data from memory.
The snoop results in the assertion of HITM#, indicating that a Snoop Agent has a copy of the requested line in the modified state.
The HITM# indication informs the Response Agent (i.e., the memory controller) that it does not have a fresh copy of the requested line. Rather, the Snoop Agent has the freshest copy of the line and will supply the line to memory and to the Request Agent.
The transaction is still a read from the Request Agent's standpoint, but from the memory controller's perspective has changed from a read by the Request Agent into a write to memory by the Snoop Agent. This is referred to as an Implicit Writeback operation.
The memory controller must provide the Implicit Writeback response in the Response Phase.
When the memory controller is ready to accept the modified line (i.e., when it has a 64-byte buffer available), it asserts TRDY# to the Snoop Agent. Assuming that the previous transaction's response has already been seen (TRDY#, if it had been asserted, has therefore been deasserted) and that memory is ready to accept the data, the memory controller asserts TRDY# to the Snoop Agent (at the start of BCLK cycle 5). If DBSY# is in the deasserted state at the start of the BCLK cycle in which TRDY# is asserted (indicating that the previous Data Bus owner has relinquished ownership), the memory controller can deassert TRDY# one clock after it asserts it (because it is assured that the Snoop Agent will detect TRDY# asserted and DBSY# deasserted one clock after TRDY# is asserted). Otherwise, the Response Agent must keep TRDY# asserted until it samples DBSY# deasserted. It then deasserts TRDY# one BCLK cycle later.
The Snoop Agent is waiting to see TRDY# asserted (indicating that memory is ready to accept the write data) and DBSY# deasserted (indicating that the Data Bus isn't in use). It keeps sampling both signals until this state is seen. It then asserts DBSY# one BCLK cycle later to take ownership of the Data Bus to supply the requested data to the Request Agent (and to write the modified line to memory).
The Snoop Agent then provides the modified line to memory and to the Request Agent. The eight qwords are provided in toggle mode order, critical qword first. If the Request Agent has only requested a subset of the line, it only accepts the data that it asked for and ignores the remaining qwords. The memory controller, however, must accept the entire line.
In addition, the Response must drive the Implicit Writeback response in the same clock that the Snoop Agent takes ownership of the Data Bus.
In the example, the Snoop Agent asserts DRDY# and starts driving the first 32 bytes of the line (and the Data Strobes) in BCLK cycle 7. Both the Request Agent and the memory controller use the falling strobe edges to latch the data into their respective input receivers.
The Snoop Agent keeps DRDY# asserted in BCLK cycle 8 and starts driving the remaining 32 bytes of the line (and the Data Strobes). Both the Request Agent and the memory controller use the falling strobe edges to latch the data into their respective input receivers.
The Snoop Agent has freshened up memory, so it changes the state of the line in its cache from modified to shared (because it detected another agent reading from the line). It should be noted, however, that the Request Agent may have been a device other than a processor and it may not have read the entire line. Nonetheless, the snooper cannot make this distinction and marks its copy of the line shared (which doesn't hurt anything).
Relaxed DBSY# Deassertion
The spec permits what is referred to as relaxed DBSY# deassertion. In BCLK cycle 8 of Figure 51-11 on page 1263, DBSY# is deasserted in the BCLK cycle in which the Data Bus owner is ready to transfer the final data item. It is permissible to keep DBSY# asserted until the final data item is transferred (BCLK cycle 9 of Figure 51-11), and then deassert both DRDY# and DBSY# at the same time. It is also permissible to keep DBSY# asserted for any number of clocks after the final data item is transferred (shall we call it “lazy” deassertion of DBSY#?). Be aware, however, that this will adversely affect the performance of the next device awaiting the release of DBSY# so that it may take ownership of the Data Bus.
A Write that Hits a Modified Line
Figure 51-12 on page 1266 illustrates a two-qword memory write that hits a modified line in the cache of one of the Snoop Agents' caches. Refer to this figure during the following discussion:
The transaction starts as a write from the Request Agent to the Response Agent (i.e., the memory controller).
The Response Agent asserts TRDY# in BCLK cycle 4 and simultaneously samples DBSY# deasserted. This means that the Request Agent will see TRDY# asserted and DBSY# deasserted at the start of BCLK cycle 5, giving it permission to take ownership of the Data Bus in BCLK cycle 6. The Response Agent can therefore deassert TRDY# one clock after it asserts it.
At the start of BCLK cycle 5 the Request Agent samples TRDY# for the first time to determine if the memory controller is ready to accept the write data (it is). In addition, DBSY# is sampled to determine if the Data Bus is still in use by the previous transaction's agents (it's not). As a result, the Request Agent acquires Data Bus ownership at the start of BCLK cycle 6.
In the Snoop Phase, a Snoop Agent that has a copy of the target line in the modified state asserts HITM# (in BCLK cycle 3). This means that the target line in memory is stale. The modified line from the Snoop Agent's cache is therefore the line that should receive the update, rather than the stale line in memory.
The assertion of HITM# informs the memory controller that it will receive write data from two sources—first the write data from the Request Agent and then the modified line from the Snoop Agent.
The Request Agent asserts DBSY# (in BCLK cycle 6), taking ownership of the Data Bus to write its data to the memory controller.
The Request Agent drives out the first of the two qwords (and the data strobes) in BCLK cycle 6 and asserts DRDY# to indicate the presence of valid data on the Data Bus.
During BCLK cycle 6, the Response Agent uses the falling-edges of the data strobes (not shown) to latch the data into its input receivers. The two qwords are placed in a buffer within the memory controller (they are NOT written to the stale line in memory).
The Response Agent samples DRDY# asserted at the start of BCLK cycle 7, validating the data received during BCLK cycle 6. All of the Request Agent's data has been written to the Response Agent. From the perspective of the Request Agent, the transaction is complete at this point.
The memory controller (i.e., the Response Agent) deasserts TRDY# at the start of BCLK cycle 5 and reasserts it at the start of BCLK cycle 7 to inform the Snoop Agent that it has a 64-byte buffer ready to accept the modified line.
The Snoop Agent samples TRDY# asserted and DBSY# deasserted at the start of BCLK cycle 8, permitting it to take ownership of the Data Bus one BCLK cycle later.
At the start of BCLK cycle 9:
- The Response Agent (i.e., the memory controller) drives the Implicit Writeback response.
- The Snoop Agent asserts DBSY# to indicate that the Data Bus is busy.
- The Snoop Agent drives the first 32 bytes of the line and the data strobes (not shown).
- The Snoop Agent asserts DRDY#, indicating that is sourcing valid data during BCLK cycle 9.
During BCLK cycle 9, the memory controller uses the falling-edges of the data strobes to latch the four qwords of data into the 64-byte buffer.
At the start of BCLK cycle 10, the Response Agent samples DRDY# asserted, indicating that valid data was received during the previous BCLK cycle.
At the start of BCLK cycle 10:
- The Snoop Agent keeps DRDY# asserted, indicating that is sourcing valid data during BCLK cycle 10.
- The Snoop Agent deasserts DBSY# to indicate that the Data Bus will no longer be busy at the end of this BCLK cycle.
- The Snoop Agent drives the final 32 bytes of the line and the data strobes (not shown).
- The Request Agent receives the response.
During BCLK cycle 10, the memory controller uses the falling-edges of the data strobes to latch the final four qwords of data into the 64-byte buffer.
At the start of BCLK cycle 11, the Response Agent samples DRDY# asserted, indicating that valid data was received during the previous BCLK cycle. This completes the transaction.
The memory controller merges the two qwords written by the Request Agent into the appropriate locations within the second memory buffer and then writes the updated line into memory.
The Snoop Agent that sourced the modified copy of the line invalidated its copy of the line after sourcing it to the memory controller (because it could not snarf the data written to memory by the Request Agent in order to update its copy).
