A method and apparatus of performing bus transactions on the bus of the computer system. The present invention includes a method and apparatus for permitting out-of-order replies in a pipelined bus system. The out-of-order responses include the sending of tokens between both the requesting agents and the responding agents in the computer system without the use of dedicated token buses.
|
0. 50. A bus agent comprising:
an address bus interface; a first logic circuit to issue an address and a request identification token to the address bus interface consecutively for a bus request as part of a bus transaction.
0. 47. An apparatus comprising:
an address bus interface; and means for issuing an address and a request identification token to the address bus interface consecutively for each bus request as part of a request phase of a bus transaction.
4. A computer system comprising:
an address bus; and a requesting agent coupled to the address bus and including, means for issuing an address and a request identification token pairs onto the address bus in consecutive bus cycles consecutively for each bus request as art part of a bus transaction. 13. A computer system comprising:
an address bus; a requesting agent coupled to the address bus and including, a first logic circuit configured to issue an address and a request identification token pairs onto the address bus in consecutive bus cycles consecutively for each a bus request as part of a bus transaction. 0. 44. A bus agent comprising:
bus interface logic to issue a request in a first bus transaction by driving an address and request identification information consecutively to an address bus interface, the bus interface logic comprising: a pending defer queue to store pending requests; a first logic circuit to recognize a subsequent deferred reply in a second bus transaction as corresponding to the request in the pending defer queue, wherein the bus agent processes the deferred reply as a response to the request substantially as if undeferred. 0. 66. A bus agent comprising:
a data bus interface; an address bus interface; a snoop interface; an arbitration interface; bus control logic coupled to said data bus interface, said address bus interface, said snoop interface, and said arbitration interface, to support a pipelined bus protocol in which multiple different transaction phases of different transactions are in some cases active on different buses during a single clock cycle, wherein the bus control logic is to signal a request and a request token consecutively on said address bus interface in a request phase of a first transaction.
23. A computer system comprising:
an address bus; a data bus; a control bus; a first bus agent coupled to the address bus, the data bus, and the control bus for performing a bus operation wherein the first bus agent initiates the bus operation by initiating a first bus transaction by driving a request address of a request and request identification information onto the address bus during consecutive clock cycles consecutively, and terminates the first bus transaction upon receiving an immediate response to satisfy the request or a deferral response indication on the control bus indicating response to the request is to be deferred.
6. A computer system comprising:
an address bus; and a requesting agent coupled to the bus and operable to issue a request onto the address bus in a first bus transaction by driving an address and request identification information onto the address bus, wherein said requesting agent comprises: a pending defer queue to store pending data requests, a first logic circuit to recognize a subsequent deferred reply on the address bus in a second bus transaction as corresponding to the request in the pending defer queue, wherein the requesting agent processes the deferred reply as a response to the request substantially as if undeferred. 29. A computer system comprising:
a bus including: an address bus; a response bus; a data bus; a requesting agent coupled to the bus, wherein the requesting agent issues a token onto the address bus for each address request and handles deferral responses in response to requests, and maintains the request as pending until receiving a deferred reply; and a responding agent coupled to the bus, wherein the responding agent generates the deferral response when a transaction cannot be completed during a predetermined time, and the responding agent generates the deferred reply, including the token, when the transaction can be completed.
7. A method of performing bus operations in a computer system having an address bus and a data bus, the method comprising steps of:
a first agent sending an address on the address bus to a second agent; sending a first token on the address bus to the second agent; providing a first response to the first agent indicating that the second agent is to provide a deferred reply in response to the address; sending a second token on the address bus to the first agent; the second agent sending the deferred reply on the address bus to the first agent; and recognizing the second token and deferred reply as corresponding to the address and the first token.
0. 52. A bus agent comprising:
an address bus interface; a data bus interface; a control bus interface; logic coupled to the address bus interface, the data bus interface, and the control bus interface to perform a bus operation wherein the bus agent is to initiate the bus operation by initiating a first bus transaction by driving a request address of a request and request identification information to the address bus interface consecutively, and is to terminate the first bus transaction upon receiving a response to satisfy the request or a deferral response indication on the control bus interface indicating response to the request is to be deferred.
0. 49. A bus agent comprising:
an address bus interface; and logic coupled to the address bus interface to issue a request to the address bus interface in a first bus transaction by driving an address and request identification information to the address bus interface, wherein said logic comprises: a pending defer queue to store pending data requests, a first logic circuit to recognize a subsequent deferred reply received at the address bus interface in a second bus transaction as corresponding to the request in the pending defer queue, wherein the bus agent processes the deferred reply as a response to the request substantially as if undeferred. 0. 59. A bus agent comprising:
an address bus interface to receive a first token associated with a request phase of a first bus transaction that is a request; and bus interface logic to provide a response indicating that a deferred reply is to be made by said bus agent to satisfy said request in response to said bus agent not being ready to complete the request, to allow the first bus transaction to complete, wherein said bus agent is to drive a second token via the address bus interface and the deferred reply as a second bus transaction when ready, the second token corresponding to the request, the deferred reply returning information requested in the request.
36. A method for performing bus transactions in a computer system having an address bus and a data bus, the method comprising:
a first agent driving an address and a first token on the address bus as part of a request to initiate a first bus transaction; the first agent receiving a deferral response from a second agent to complete the first bus transaction; the first agent receiving a deferred reply as part of a second bus transaction, wherein receiving the deferred reply comprises receiving a second token on the address bus; and the first agent identifying the deferred reply as corresponding to the request, such that the request is completed using two bus transactions.
0. 54. A bus agent comprising:
an address bus interface; a data bus interface; a control bus interface; logic coupled to the address bus interface, the data bus interface, and the control bus interface to perform a bus operation wherein the bus agent is to initiate the bus operation by initiating a first bus transaction by driving a request address of a request to the address bus interface and request identification information during a first phase of the first bus transaction, and is to terminate the first bus transaction upon receiving a response to satisfy the request or a deferral response indication on the control bus interface indicating response to the request is to be deferred.
30. A method of performing bus operations in a computer system having an address bus and a data bus, the method comprising:
a first agent sending an address on the address bus to a second agent; sending a first token on the address bus to the second agent; the first agent receiving a first response from the second agent indicating that the second agent is to provide a deferred reply in response to the address; the first agent receiving a second token driven on the address bus by the second agent; the first agent receiving the deferred reply driven on the address bus by the second agent; and recognizing the second token and deferred reply as corresponding to the address and the first token.
1. A computer system comprising:
an address bus; and a requesting agent coupled to the bus and operable to issue a request onto the bus in a first bus transaction by driving an address onto the address bus in a first clock cycle of the first bus transaction and request identification information consecutively onto the address bus in a second clock cycle of the first bus transaction , wherein said requesting agent comprises: a pending defer queue to store pending requests, a first logic circuit to recognize a subsequent deferred reply on the bus in a second bus transaction as corresponding to the request in the pending defer queue, wherein the requesting agent processes the deferred reply as a response to the request substantially as if undeterred undeferred. 39. A method for performing bus operations in a computer system having an address bus and a data bus, the method comprising:
a first agent receiving an address on the address bus for a bus request as part of a bus operation from a second agent; providing a first response to the second agent indicating that the first agent is to provide a deferred reply in response to the address and the first agent receiving a first token from the address bus; the first agent driving a second token on the address bus; and the first agent sending the deferred reply to the second agent to complete the bus operation once the second agent receives and the second token from the address bus and identifies the second token as corresponding to the bus operation.
20. A method for performing bus transactions in a computer system having an address bus and a data bus, the method comprising the steps of:
a first agent driving an address and a first token on the address bus as part of a request to initiate a first bus transaction; latching the first token; sending a deferral response in response to the request; the first agent receiving the deferral response to complete the first bus transaction; a second agent sending a deferred reply as part of a second bus transaction, wherein the step of sending a deferred reply comprises sending a second token on the address bus; and the first agent identifying the defined reply corresponding to the request, such that the request is completed using two bus transactions.
0. 64. A system comprising:
a data bus; an address bus; a snoop bus; an arbitration bus; a requesting bus agent coupled to said data bus, said address bus, said snoop bus, and said arbitration bus, said requesting bus agent to support a pipelined bus protocol in which multiple different transaction phases of different transactions are in some cases active on different buses during a single clock cycle, wherein the requesting bus agent is to signal a request and a request token consecutively on said address bus in a request phase of a first transaction; a responding bus agent coupled to said data bus, said address bus, said snoop bus, and said arbitration bus, said responding bus agent to provide a defer indication to said requesting bus agent to end said first transaction.
15. A method for performing bus operations in a computer system having an address bus and a data bus, the method comprising steps of:
a first agent initiating a bus request as part of a bus operation, wherein the step of initiating a bus request comprises driving an address on the address bus a first agent driving a first token on the address bus; providing a first response to the first agent indicating that a second agent is to provide a deferred reply in response to the address and the second agent receiving the first token from the address bus; the second agent driving a second token on the address bus; the second agent sending the deferred reply to the first agent; the first agent receiving the second token from the address bus; the first agent identifying the second token as corresponding to the bus operation; and receiving the deferred reply by the first agent, thereby completing the bus operation.
0. 68. A bus agent comprising:
a data bus interface; an address bus interface; a snoop interface; an arbitration interface; bus control logic coupled to said data bus interface, said address bus interface, said snoop interface, and said arbitration interface, to support a pipelined bus protocol in which multiple different transaction phases of different transactions are in some cases active on different buses during a single clock cycle, to provide a defer indication to end a first transaction in response to a consecutively received address and a token received on said address bus interface during a request phase of the first transaction, said bus control logic to initiate a second transaction in which said token is driven on said address bus interface during a second transaction request phase and wherein information requested in the first transaction is provided during a data phase of the second transaction.
28. A method of performing bus transactions in a computer system having a requesting agent and a responding agent each coupled to a bus which includes a response bus, an address bus, and a data bus, the method comprising the steps of:
the requesting agent requesting a first bus transaction by issuing an address and a token onto the address bus; and if the responding agent is ready to perform the first bus transaction, the responding agent driving an in-order completion response onto the response bus in a response phase of the first bus transaction; and if the responding agent is not ready to perform the first bus transaction, then the responding agent driving a deferral response onto the response bus in the response phase of the first bus transaction, and when the responding agent becomes ready to respond, then the responding agent initiating a second bus transaction and driving a deferred reply onto the address bus, a second token onto the address bus, and any requested data onto the data bus, in response phase of the second bus transaction. 2. The computer system defined in
3. The computer system defined in
a latch coupled to receive a token identifying the subsequent deferred reply on the bus; matching logic coupled to the latch and configured to compare an identification (ID) of the requesting agent to a first portion of the token, wherein the requesting agent indexes the pending defer queue with a second portion of the token if the matching logic determines that the ID matches the first portion of the token.
5. The computer system of
means for responding to a deferred reply on the address bus as if not deferred.
8. The method defined in
9. The method defined in
11. The method defined in
12. The method defined in
14. The computer system of
a second logic circuit configured to respond to a deferred reply on the address bus as if not deferred.
16. The method defined in
17. The method defined in
18. The method defined in
19. The method defined in
21. The method defined in
22. The method defined in
24. The computer system defined in
25. The computer system defined in
26. The computer system defined in
27. The computer system deferred in
31. The method defined in
32. The method defined in
34. The method defined in
35. The method defined in
37. The method defined in
38. The method defined in
40. The method defined in
41. The method defined in
42. The method defined in
43. The method defined in
0. 45. The bus agent defined in
0. 46. The bus agent defined in
a latch coupled to receive a token identifying the subsequent deferred reply on the address bus interface; matching logic coupled to the latch to compare an identification (ID) of the bus agent to a first portion of the token, wherein the bus agent is to index the pending defer queue with a second portion of the token if the matching logic determines that the ID matches the first portion of the token.
0. 48. The apparatus of
means for responding to a deferred reply on the address bus interface as if not deferred.
0. 51. The bus agent of
a second logic circuit configured to respond to a deferred reply on the address bus interface as if not deferred.
0. 53. The bus agent of
0. 55. The bus agent of
0. 56. The bus agent defined in
0. 57. The bus agent defined in
0. 58. The bus agent defined in
0. 60. The bus agent of
0. 61. The bus agent of
an arbitration signal interface; a snoop signal interface; a data bus interface, wherein said bus agent is to support a pipelined bus protocol, allowing different phases of different transactions to be active during a single bus clock cycle.
0. 62. The bus agent of
0. 63. The bus agent of
0. 65. The system of
a defer enable signal line, wherein said requesting bus agent is to generate an active defer enable signal on said defer enable signal line during the request phase of said first transaction; a defer signal line, wherein said responding bus agent is to generate an active defer signal on said defer signal line during a snoop phase of said first transaction to provide a first portion of said defer indication; a plurality of response signal lines, wherein said responding bus agent is to generate a defer response encoding on said plurality of response signal lines during a response phase to provide a second portion of said defer indication.
0. 67. The bus agent of
a defer enable interface, wherein said bus control logic is to generate an active defer enable signal on said defer enable interface during the request phase of said first transaction, and further wherein said bus control logic is to end said first transaction in response to a defer signal in a snoop phase and a deferral encoding on a response bus in a response phase.
0. 69. The bus agent of
a defer enable interface, wherein said bus control logic is only to provide the defer indication if an active defer enable signal is received on the defer enable interface during the request phase of said first transaction; and a defer signal interface, wherein said bus control logic is to generate an active defer signal on said defer signal interface during a snoop phase of said first transaction to provide a first portion of said defer indication; a response interface, wherein said bus control logic is to generate a defer response encoding on said response interface during a response phase to provide a second portion of said defer indication only if no hit modified signal is received on said snoop interface during said snoop phase.
0. 70. The apparatus of
a data bus interface; a snoop interface; means for participating in different transaction phases for different transactions on two of said data bus interface, said address bus interface, and said snoop interface.
0. 71. The apparatus of
a defer enable signal interface; means for asserting an active defer enable signal during the request phase of the bus transaction to allow said bus transaction to be deferred; a defer signal interface; means to receive an active defer signal on said defer signal interface during a snoop phase of the bus transaction and a deferral response during a response phase of the bus transaction and to conclude said bus transaction in response to said active defer signal and said deferral response.
0. 72. The bus agent of
a defer enable signal interface; a defer signal interface; a response interface; a second logic circuit to assert an active defer enable signal during a request phase of the bus transaction to allow said bus transaction to be deferred and to receive an active defer signal from said defer signal interface during a snoop phase of the bus transaction and a deferral response encoding on said response interface in a response phase and to conclude said bus transaction in response to said active defer signal and said deferral response encoding.
0. 73. The bus agent of
|
|||||||||||||||||||||||||||
This is a continuation of application Ser. No. 08/302,600, filed Sep. 8, 1994, now Pat. No. 5,615,343 which is a continuation-in-part of application Ser. No. 08/085,541, filed Jun. 30, 1993, Pat. No. 5,568,620.
The invention relates to the field of protocols for computer system buses; particularly, the present invention relates to protocols for buses that perform deferred/out-of-order transactions.
In a computer system, transfers between devices such as processors, memories, input/output (I/O) units and other peripherals generally occur according to a protocol. These devices are commonly referred to as agents. The protocol is a method of handshaking that occurs between the devices during a transfer which allows each device involved in the transfer to know how the other device is going to act or perform.
Typically, transfers of data and information in a computer system are performed using multiple buses. These buses may be dedicated buses between only two devices or non-dedicated buses that are used by a number of units, bus agents or devices. Moreover, buses in the system may be dedicated to transferring a specific type of information. For instance, an address bus is used to transfer addresses, while a data bus is used to transfer data.
A bus transaction normally includes a requesting device, or agent, requesting data or a completion signal from another agent on the bus. The request usually includes some number of control signals indicating the type of request accompanied by the address of the desired data or the desired device. The device which is mapped into the address space containing the requested address responds by sending a completion signal along with any data as necessary.
In some computer systems, bus transactions occur in a pipelined manner. When bus transactions are pipelined, the requests from numerous bus agents are pending at the same time. This is possible due to the fact that separate data and address buses are used. In a pipelined transaction, while an address of a request is being sent on the address bus, the data or signals corresponding to a previously requested address (on the address bus) may be returned on the data bus. In certain pipelined systems, the completion responses occur in the same order as they were requested. However, in other pipelined systems, the order of the completion responses does not have to occur in the same order as their corresponding requests. This type of bus system is commonly referred to as a split transaction bus system.
In split transaction buses, a request is initiated with a first bus transaction to one of the agents in the computer system. If the responding agent cannot provide the response to the request at this time, the response corresponding to the request may be disassociated from the request. Eventually, when the response is ready, the response with optional data is returned to the requesting agent. The requests may be tagged so that they may be identified by the requesting agent upon their return.
To accommodate split transactions, the systems require some capability of associating a response with its address (i.e., its request). One approach is to use two separate token buses and a deferred bus. When performing a request, an address is driven onto the address bus. At the same time, a token is driven on the first token bus. This token is associated with the address request. The token is received by the agent which is to respond to the address request (i.e., the responding agent). When the agent is able to respond at this time, the responding agent drives the token on the second token bus and the appropriate response on the data bus.
Using two token buses increases the number of pins that are required to interface with the external bus. For tokens that are 8-bits in size, using two separate token buses requires an additional sixteen pins to be added to the computer system, as well as additional space allocated on the computer board for the token buses. Moreover, the pins used to support the token buses must also be added to every bus agent package in the system. An increase in the number of pins often equates to an increase in the cost of the package. Thus, the cost of integrated circuit components in the system increases. On the other hand, the increase in bandwidth due to permitting split transactions is significant due to the ability to reorder long latency transactions behind short latency transactions issued later. It is desirable to support split bus transactions without incurring most of the increased cost of modifying integrated circuit components and the increased number of pins required.
In the prior art, some responding agents provide a retry response in response to a request from a bus agent. The retry response indicates to the bus agent sending the request that the responding agent is not ready to respond and that the request should be tried again later. The requesting agent then polls the responding agent from time to time to identify its availability for the transfer. After giving a retry response, the responding agent may continue processing the request. When it is ready to complete the transaction, it gives a completion response to the requesting agent and terminates polling. One problem with such a scheme is that the unnecessary polling increases bus traffic. It is desirable to reduce bus traffic when providing a retry response. Note that it is also desirable to minimize cost for bus agents unable to accomodate split transactions.
The present invention provides a method and apparatus for implementing such a bus protocol. The protocol of the present invention provides a method and apparatus for accommodating split transactions without the use of separate token buses and without the increased number of pins associated with them.
A method and apparatus for performing split bus transactions in a computer system is described. The computer system includes separate data and address buses that allow bus transactions to occur in a pipelined manner. The present invention includes a method and apparatus for initiating a first bus transaction and driving a request address on the address bus. The request address is driven by a requesting device, or agent. The responding agent drives a deferral response if unable to respond at this time. The present invention also includes a method and apparatus for driving a first token by the requesting agent on the address bus associated with the request and the address. The request address is driven on a common multiplexed address bus during the first clock and the token is driven on the common multiplexed address bus during the second clock. A responding device receives the first token and may store it internally for later use when the responding device is ready to, or is capable of, satisfying the address request. Once stored, the first bus transaction has completed.
When the responding device is ready, or is capable of, satisfying the request (e.g., the data is ready, the completion signals may be sent, etc.), the responding device initiates a second bus transaction and drives a second token on the address bus. Also the responding device drives any necessary data onto the data bus which corresponds to the original address request. In one embodiment, the second token is identical to the first token. The original requesting device receives the second token and compares the second token to the first token corresponding to its original address request. Upon determining that a match exists, the requesting device receives the completion signals and receives the data, if any, from the data bus, thus completing the second bus transaction.
The present invention will be understood more fully from the detailed description given below and from the accompanying drawings of various embodiments of the invention, which, however, should not be taken to limit the invention to the specific embodiments, but are for explanation and understanding only.
A method and apparatus for accommodating split transactions in a computer system is described. In the following detailed description of the present invention numerous specific details are set forth, such as token size, queue size, etc., in order to provide a thorough understanding of the present invention. However, it will be apparent to one skilled in the art that the present invention may be practiced without these specific details. In other instances well known methods, functions, components and procedures have not been described in detail as not to obscure the present invention.
Overview of the Computer System of the Present Invention
Referring first to
As illustrated in
A level three (L3) cache memory 111 for temporarily storing data and instructions for use by other devices in the computer system (e.g., processor 102, etc.) and a L3 cache controller 110 for controlling access to L3 cache memory 111 are also coupled to processor-memory bus 101.
A memory controller 122 is coupled with processor-memory bus 101 for controlling access to a random access memory (RAM) or other dynamic storage device 121 (commonly referred to as a main memory) for storing information and instructions for processor 102.
An input/output (I/O) bridge 124 is coupled to processor-memory bus 101 and I/O bus 131 to provide a communication path or gateway for devices on either processor-memory bus 101 or I/O bus 131 to access or transfer data between devices on the other bus. Bridge 124 performs functions such as turning the byte/word/double-word data transfer traffic from I/O bus 131 into line size traffic on processor-memory bus 101.
I/O bus 131 communicates information between devices in the computer system. Devices that are coupled to I/O bus 131 include a display device 132, such as a cathode ray tube, liquid crystal display, etc., for displaying information to the computer user, an alphanumeric input device 133 including alphanumeric and other keys, etc., for communicating information and command selections to other devices in the computer system (e.g., processor 102) and a cursor control device 134 for controlling cursor movement. Moreover, a hard copy device 135, such as a plotter or printer, for providing a visual representation of the computer images and a mass storage device 136, such as a magnetic disk and disk drive, for storing information and instructions may also be coupled to I/O bus 131.
Of course, other embodiments of the present invention may not require nor include all of the above components, while other embodiments require or include additional components. For example, in certain embodiments, L3 cache controller 110 and L3 cache memory 111 may not be required. Also, the computer system may include an additional processor coupled to the processor-memory bus 101. The additional processor may comprise a parallel processor, such as a processor similar to or the same as processor 102, or may comprise a co-processor, such as a digital signal processor. In such embodiments, processor 102 and the additional processor(s) reside directly on a processor-memory bus 101. In other embodiments, it may not be required to provide a display device for displaying information.
Bus Transactions in the Present Invention
In the present invention, devices and units in the computer system perform bus transactions on the processor-memory bus. In one embodiment, the address bus and portions of the control bus of the processor-memory bus together function as a "request" bus for initiating and responding to requests. This "request" bus is used by the initiator of a request (e.g., a requesting agent) to transfer the request type and address and same bus is used by observers (e.g., responding agents) of the request to transfer their status or response for the issued transaction. The data bus transfers data being read or written.
In one embodiment, bus activity is hierarchically organized into operations, transactions, and phases. An operation is a bus procedure that appears atomic to software such as reading a naturally aligned memory location. Executing an operation usually requires one transaction but may require multiple transactions, such as in the case of deferred replies in which requests and replies are different transactions. A transaction is the set of bus activities related to a single request, from request bus arbitration through response-initiated data transfers on the data bus.
A transaction contains up to six phases. However, certain phases are optional based on the transaction and response type. A phase uses a particular signal group to communicate a particular type of information. In one embodiment, the six phases are:
Arbitration
Request
Error
Snoop
Response
Data
The data phase is optional and used if a transaction transfers data on the data bus. The data phases are request-initiated, if the data is available at the time of initiating the request (e.g., for a write transaction), and response-initiated, if the data is available at the time of generating the transaction response (e.g., for a read transaction).
Different phases from different transactions can overlap, thereby pipelining bus usage and improving bus performance.
After the requesting agent becomes the bus owner, the transaction enters the Request Phase, in which the bus owner drives a request, and address information on the bus. The Request Phase is two clocks in duration. In the first clock, the ADS# signal is driven along with the transaction address and sufficient information to begin snooping and memory access. In the second clock, information used to identify the request (e.g., a token) and information about the length of the transaction are driven, along with other transaction information.
After the Request Phase, a new transaction enters a first-in-first-out (FIFO) queue, the In-Order queue. All bus agents, including the requesting agent, maintain an In-Order queue and add each new request to those queues. For more information on the in-order queue, see U.S. patent application Ser. No. 08/206,382 entitled "Highly Pipelined Bus Architecture", filed Mar. 1, 1994, assigned to the corporate assignee of the present invention and incorporated herein by reference. In
The third phase of every transaction is an Error Phase, three clock cycles after the Request Phase. The Error Phase indicates any immediate (parity) errors triggered by the request.
If the transaction isn't canceled due to an error indicated in the Error Phase, a Snoop Phase is entered, four or more cycles from the Request Phase. The results of the Snoop Phase indicate if the address driven for a transaction references a valid or modified (dirty) cache line in any bus agent's cache. The Snoop Phase results also indicate whether a transaction will be completed in-order or may be deferred for possible out-of-order completion.
Transactions proceed through the In-Order Queue in FIFO order. The topmost transaction in the In-Order Queue enters the Response Phase. The Response Phase indicates whether the transaction has failed or succeeded, whether the transaction completion is immediate or deferred, whether the transaction will be retired and whether the transaction includes a Data Phase.
The valid transaction responses are: normal data, implicit writeback, no data, hard failure, deferred, and retry.
If the transaction does not have a Data Phase, the transaction is complete after the Response Phase. If the request action has write data to transfer, or is requesting read data, the transaction has a Data Phase which may extend beyond the Response Phase.
In one embodiment, not all transactions contain all phases, not all phases occur in order, and some phases can be overlapped. All transactions that are not canceled in the Error phase have the Request, Error, Snoop, and Response Phases. Also, arbitration may be explicit or implicit in that the Arbitration Phase only needs to occur if the agent that is driving the next transaction does not already own the bus. The Data Phase only occurs if a transaction requires a data transfer. The Data Phase can be absent, response-initiated, request-initiated, snoop-initiated, or request- and snoop-initiated. The Response Phase overlaps the beginning of the Data Phase for read transactions (request-initiated data transfers or snoop-initiated data transfers). The Request Phase triggers the Data Phase for write transactions (request-initiated data transfers).
Bus Protocol of the Present Invention
In the present invention, operations are performed on the processor-memory bus according to a bus protocol. The devices and units in the computer system of the present invention represent both requesting agents and responding agents. A requesting agent is a device which is capable of requesting a bus operation that involves receipt of one or more completion signals and, optionally, data from another device. A responding agent is a device which is capable of responding to the request by sending the necessary signals and, optionally, data in response to the request. Responding agents that are able to accommodate split transactions are referred to herein as "smart" responding agents, while responding agents that cannot accommodate split transactions are referred to herein as "dumb" responding agents. Note that in the following description, the terms "agent" and "device" may be used interchangeably.
In the present invention, bus transactions occur on the buses in the computer system in a pipelined manner. That is, multiple bus transactions may be pending at the same time, wherein each is not fully completed. Therefore, when a requesting agent begins a bus transaction, the bus transaction may only be one of a number of bus transactions currently pending. Although bus transactions are pipelined, the bus transactions in the present invention do not have to be fully completed in order. The present invention allows for some of the completion replies to requests to be out-of-order by supporting deferred transactions. Non-split transactions are completed in order.
The present invention accommodates deferred transactions by essentially splitting a bus operation into two independent bus transactions. The first bus transaction involves a request (for data or completion signals) by a requesting agent, and a response by the responding agent. The request may include sending an address on the address bus. The request may also include the sending of a token, which the requesting agent uses to identify its request. The response may include the sending of completion signals (and possibly data) if the responding agent is ready to respond. In this case, the bus transaction ends, as well as the bus operation. However, if the responding agent is not ready to respond to the request (e.g., the completion signals and/or the optional data are not ready), the response may include providing an indication to the requesting agent that its response to the request will be deferred. This indication will be referred to herein as a deferral response.
In case of a deferral response, the bus operation comprises a second transaction that includes the responding agent sending a deferred reply with the completion signals and requested data (if any) to the requesting agent, such that the requesting agent completes the transaction. In one embodiment, the deferred reply includes completion signals (and possibly data) and comparison request identifying information. The request identifying information comprises the token. That is, the token is resent by the responding agent to the requesting agent so that the requesting agent can associate the deferred reply with the original request. Deferred and non-deferred bus transactions according to one embodiment of the present invention are depicted in the flow chart of FIG. 3.
Referring to
Once a request has been placed onto the bus, a determination of which device is to be the responding agent occurs (processing block 303). This determination includes a responding agent recognizing the address that was driven onto the address bus. In one embodiment, the responding agent is the device which is mapped into the address space that includes the address of the request.
The responding agent then determines if it is ready to respond (processing block 304). In case of a read operation, the responding agent is ready to respond if the data requested is available. In case of a write operation, the responding agent is ready to respond if it begins completing the write operation upon receipt, or, if capable of a post write, the responding agent is ready to respond as soon as the data and address are received (where the actual writing of the data is finished later). If the responding agent is ready to respond, then the responding device sends an "in-order" completion response indication and drives the necessary signals or data on the data bus at the appropriate time (processing block 205), thereby ending the bus transaction, and the bus operation as non-deferred.
If the responding agent is not ready to complete the bus transaction, then the responding agent latches the first token from the address bus and sends a deferral response at its appropriate response time (processing block 306). The responding agent may not be ready to respond if the data is not ready by the time the responding agent is required to respond in case of a read operation. The responding agent may not be ready to respond until a write operation has been completely finished, such as in the case of a write to an I/O device.
The requesting agent receives the deferral response on the bus at the appropriate time (processing block 307). The appropriate time is dictated by the pipelined nature of the system bus, which will be described in more detail below.
A number of additional bus transactions may be run on the bus after the requesting agent receives the deferral response before the responding agent is finally able to satisfy the request. When the responding agent is ready to complete the deferred bus operation (e.g., the data does become available to the responding agent), the responding agent arbitrates for ownership of the address bus and the control bus (e.g., the request bus) (processing block 308).
Once ownership has been granted to the responding agent, the responding agent sends a deferred reply (processing block 309). As part of the deferred reply, the responding agent sends a second token on the address bus, a deferred reply signal (e.g., command) on the control bus and any appropriate data on the data bus. In one embodiment, the second token is the same as the first token; however, in other embodiments, the first and second tokens may not be the same, yet have a unique relationship to allow agents to correctly associate one with the other.
The requesting agent monitors the address bus, along with other agents, and receives the token (processing block 310). The requesting agent latches the second token. The requesting agent then determines whether the second token sent from the responding agent matches one of the outstanding tokens in its pending request queue (processing block 311). In such a case, the requesting agent performs a token match between the second token sent from the responding agent and the first token, or any other token stored in the requesting agent. It should be noted that in the present invention, the requesting agent is always monitoring the address bus for addresses and agent IDs and constantly determines if the signals on the address bus represent an address within the address range mapped to the agent or if the signals represent a token.
If the requesting agent determines that second token from the responding agent does not match the first token, then the data on the data bus and the completion signal(s) are ignored (processing block 312). If the requesting agent determines that second token from the responding agent matches the first token, then the deferred reply data on the data bus and/or the completion signals is the data or completion signals originally requested by the requesting agent and the requesting agent receives the completion signals and/or latches the data on the data bus (processing block 313), thus completing the second bus transaction. After receiving the completion signals and/or data corresponding to the original request, the entire bus operation ends. Thus, the bus transaction occurs between the responding agent and the requesting agent and the original bus operation is completed.
After a device has been determined to be the responding agent, the responding agent is responsible for generating a response to ensure that bus retains its pipelined nature. A responding agent may not be able to complete the requested bus transaction at the appropriate times. For example, the data requested may not be available. The data may not be available for numerous reasons. For example, the data may not be available due to long access times of a particular device. Also, the preparation of a response to satisfy the request may require a large number of cycles to complete due to the structure or the nature of a particular device.
Therefore, in the event that the responding agent cannot complete the requested bus transaction at the appropriate times, the responding agent sends a deferral response. The responding agent sends either the requested data or completion signals (if ready to respond) or a deferred completion indication comprising a deferral response (if unable to supply the requested completion signals or the requested data) at the appropriate time.
The appropriate time for a responding agent to generate a response is defined as that time at which the responding agent must respond with some type of response in order to retain the order of the responses on the data bus with those requests that occurred on the address bus, thereby ensuring the pipelined nature of the bus of the present invention. In other words, the order of the "responses" on the data bus must occur in the same order as the "requests" on the address bus. Therefore, some type of response to a particular request must appear on the data bus after the response of the request which immediately preceded the particular request on the address bus. If some type of response is not possible in a reasonable time (e.g., ten bus clocks), then all of the subsequent responses will be stalled by the agents responsible for generating them, hurting system performance. Note that the response itself may also be stalled.
To accommodate multiple pending requests that require deferred replies, the responding agent upon completing the bus cycle with a deferral response must be capable of designating the deferred reply with a particular request if the responding agent is to be able to accommodate multiple requests while one or more requests are pending. For example, when data is requested from the cache memory (e.g., L3 cache memory) and the cache controller sends a deferral response, if the cache memory is to be accessed while this request is pending, the responding agent (e.g., the cache controller) must include a mechanism to associate the data that becomes available to the request which requested it. In one embodiment, in processing block 306 the responding agents store deferred requests (and associated tokens) for which a deferral response is generated. When the data is available, the responding agent is able to identify the destination of the data using the stored token and deferred request. The responding agent is responsible for maintaining consistency when it provides a deferral response, such as when there are multiplie requests to the same cache line.
The token latched by the responding agent is used as a future reference between the requesting or responding agent to identify the response to the requesting agent when made by the responding agent. The requesting agent using the token stored in the transaction pending queue (with an indication of the request with which it was associated) watches for the response to the request. When the responding agent is ready to complete the bus transaction, the same token (used when sending the request) is sent on the address bus. In one embodiment, a special command is used to indicate to agents on the bus that the address bus has a token instead of an address. Associated with the special command (e.g., control signal(s)) is the data (on the data bus) that was originally requested, if any, by the requesting agent. In this manner, the subsequently sent token re-establishes contact with the requesting agent.
Deferred Operations
During the Request Phase of a bus transaction, an agent may assert a Defer Enable (DEN#) signal to indicate if the transaction can be given a deferred response. Note that the "#" symbol indicates that the signal is active low. When the DEN# signal is deasserted, the transaction must not receive a deferred response. In one embodiment, all transactions in a buslocked operation, deferred reply transactions, and writeback transactions cannot be deferred. Transaction-latency sensitive agents can also use the DEN# signal feature to guarantee transaction completion within a restricted latency.
A DEFER# signal in conjunction with a HITM# signal are used to determine when a response is to be deferred. The HITM# signal, when asserted, indicates the presence of modified data in the cache. In-order completion of a transaction is indicated by the DEFER# signal being deasserted or the HITM# signal being asserted during the Snoop Phase, followed by normal completion or implicit writeback response in the Response Phase. When the Defer Enable (DEN#) signal is inactive (and the HITM# signal deasserted), the transaction can be completed in-order or it can be retried, but not deferred. Thus, any bus agent incapable of supporting a deferred response may use this to be compatible, requiring that the transaction be completed in-order as described above or retried. A transaction can be retried when the DEFER# signal is asserted and the HITM# signal is non-asserted during the Snoop Phase followed by a retry response during the Response Phase. That is, a bus agent incapable of supporting a deferred response will provide a retry response if unable to provide the required response at the time of the Response Phase.
When Defer Enable (DEN#) is asserted, the transaction can be completed in-order, can be retried, or deferred. When a transaction is to receive a deferred reply, the DEFER# signal is asserted (while the HITM# signal is deasserted) during the Snoop Phase followed by a deferral response in the Response Phase.
It is the responsibility of the agent addressed by the transaction to assert the DEFER# signal. In another embodiment, the responsibility can be given to a third party agent who can assert the DEFER# signal on behalf of the addressed agent.
In the present invention, a requesting agent assumes that every outstanding transaction issued with an asserted Defer Enable (DEN#) signal in the Request Phase may be completed with a deferred reply. To account for the possibility that each issued transaction may receive a deferred response, the requesting agent maintains an internal outstanding transaction queue, referred to herein as the pending request queue. Each entry in the queue has an ID. The number of queue entries (and the number of IDs) is equal to the number of requests the agent is able to issue and have pending. During the deferred reply of the second transaction, the requesting agent must compare the reply sent on the address bus with all deferred IDs in its pending request queue. On an ID match, the requesting agent can retire the original transaction from its queue and complete the operation.
If a responding agent is unable to guarantee in-order completion of a transaction, the responding agent asserts a DEFER# signal in the transaction's Snoop Phase to indicate that the transaction is to receive a deferred reply or is to be aborted. If the DEFER# signal is not overridden by another caching agent asserting the HITM# signal (indicating a hit to a modified line in the cache) in the Snoop Phase, then the responding agent owns the transaction response. The response of the responding agent is determined by its reply policy. If the responding agent is capable of and desires completing the request in a subsequent independent bus transaction, then it generates a deferral response.
After issuing a deferral response and once ready to respond, the responding agent issues a second independent bus transaction to complete the earlier request for which the response was deferred. This second transaction may return data to complete an earlier transaction (e.g., in case of a read operation), or it may simply indicate the completion of an earlier transaction (e.g., in case of a write operation).
In the Snoop Phase, the addressed agent determines that the transaction cannot be completed in-order and hence asserts the DEFER# signal in T5. In T7, the addressed agent becomes the responding agent due to deasserted state of the HITM# signal in T6. The responding agent returns a deferral response in T7 by asserting the proper encoding on the RS[2:0]# signals. The RS[2:0]# signals are used to encode different types of responses, including a deferral response. Note that the responding agent stores the token latched from the address bus.
Prior to T9, the addressed responding agent obtains the data required in the original request. In T9, the responding agent issues a second transaction, using the token from the original transaction as the address. In T13, the response agent drives a valid information on the HITM# signal and the HIT# signal to indicate the final cache state of the returned line. The requesting agent picks up snoop responsibility. In T15, the responding agent drives normal completion response and begins the optional Data Phase, if necessary. The responding agent returns a successful completion response with data on the bus and drives data during T15-T18, which is received during T16-T19. In T21, the entire bus operation, consisting of the first and second transactions, is complete.
Note that in T10, the requesting agent observes the second transaction. The requesting agent compares the token received from the address bus with the token corresponding to the original request. The requesting agent observes the final state of the returned cache line in T14. In T16, the requesting agent receives the deferred reply and removes the transaction from its pending request queue (and the In-Order queue). This completes the bus operation.
In one embodiment, a memory agent or I/O agent in the computer system may defer a response on any request other than a bus locked request, another deferred reply transaction, or a cache line write designated for explicit writeback.
In the present invention, the deferred reply "wakes" up the original transaction. That is, the original transaction carries on and completes as if the requesting agent had initiated the transaction. For instance, when a memory agent returns a deferred reply to a processor in the system, the memory controller is not the master, and the processor acts as if it had initiated the transaction, responding to the handshaking on the bus.
Receiving a deferred reply removes the transaction from the In-Order queue. In order to complete the original request, the responding agent initiates a second independent transaction on the bus. The token (e.g., deferred reply ID), latched during the original transaction, is used as the address in the Request Phase of the second transaction.
In one embodiment, a token (e.g., deferred ID) contains eight bits, DID[7:0]#, divided into two four-bit fields. An exemplary token is shown in FIG. 5. The token is transferred on A[23:16]# (carrying, DID[7:0]#) in the second clock of the original transaction's Request Phase. Address bus lines A[23:20]# contain the response agent ID, which is unique for every responding agent. Address bus lines A[19:16]# contain a request ID, assigned by the request agent based on its internal queue. An agent that supports more than sixteen outstanding deferred requests can use multiple agent IDs. In one embodiment, only four outstanding deferred requests may be supported by the processor of the computer system.
To complete the transaction, the address bus is used to return the token, which was sent with the request on DID [7:0]#. In the Request Phase of the second transaction, the token is driven on A[23:16]# on the first clock of the request phase. In the second clock of the Request Phase, the responding agent's identifier and transaction ID are driven (although not used by the original requesting agent). During the Response Phase, the deferred reply is driven along with any data during the Data Phase. The requesting agent decodes the token returned on A[23:16]# and compares it with previously deferred requests. The requesting agent compares A[23:20]# with its agent ID to see if there is a match. In case of a match, the requesting agent uses A[19:16]# as an index to point to the proper entry in its pending request queue. (Exemplary matching hardware is shown in FIG. 6.).
Responding Agent Embodiments
In the present invention, some responding agents never defer requests, some responding agents always defer requests, and some responding agents defer requests for certain operations and not other operations.
In the above illustrated embodiments, one agent may be the memory agent or I/O agent in a deferred operation.
If a caching memory controller, such as L3 cache controller 110, is in the computer system, the cache controller may also generate the deferred responses on read operations when the read data is not immediately available in the cache memory. The L3 cache controller will then proceed to obtain the data from the memory, such as main memory 121, while servicing any subsequent requests for data available in the L3 cache memory. When the read response is ready, the L3 cache controller arbitrates for the bus and returns the read data.
If an I/O bridge is in the computer system, the I/O bridge may defer bus transactions. It should be noted that this is typically performed according to an I/O bus standard, such as the PCI, EISA, ISA, MCA, PCMCIA, VESA standard. Generally, accesses to devices residing on the I/O bus take longer to complete than accesses issued to the memory devices. In a highly pipelined bus involving requests generated from multiple requesting agents, there is an intermix of I/O operations and memory operations. In order to eliminate the stalling effect of I/O accesses in subsequent memory accesses, the I/O bridge of the present invention may generate a deferred response to accesses directed towards itself (and the devices on the I/O bus). In one embodiment, the I/O bridge of the present invention has the hardware necessary for deferring multiple bus requests. When the response is ready, the I/O bridge arbitrates for the bus and initiates a deferred reply (a second independent transaction).
Token Generation and Recognition Hardware
In the present invention, each of the requesting and responding agents supports additional functionality in order to utilize the deferred protocol. In the present invention, the agents capable of deferral and deferred responses function as a bus master. Being a bus master according to the present invention comprises the ability to arbitrate for the bus and carry out a request transfer cycle. This allows the response agent to initiate the second transaction and to obtain control of the bus when completion signals or data is ready subsequent to the responding agent providing a deferral response. For instance, the processors are bus masters generally. On the other hand, memory controllers generally are not bus masters and, thus, would need to have this ability to initiate the later transactions to complete the bus operation.
In the illustrated embodiment, token generation is the responsibility of the requesting agent. One embodiment of a token of the present invention is shown in FIG. 5. Referring to
As shown in
A responding agent that is capable of deferred responses maintains an internal deferred request queue for storing tokens latched from the address bus when providing a deferral response. In one embodiment, this queue contains 16 entries, but may have more or less (e.g., 2-32 entries). In the present invention, only a small queue depth is sufficient since the comparison hardware need support only the entries that are actually deferred.
One embodiment of a request queue in a responding agent is shown in FIG. 6. Referring to
In one embodiment, token field 601 comprises four bits and represents an index, REQ field 602 comprises 5 bits×2, BE field 603 comprises eight bits muxed, and address field 604 comprises 36 bits. The token field 601 may be implicit in the hardware and, hence, may not be physically implemented in the hardware. In one embodiment, the token field 601 is not implemented in hardware when the position of the entry in the queue is the same as the token field contents. Note also that the index of the token field may be a randomly generated value.
Also shown in
At the time the responding agent wishes to provide a deferral response, the responding agent assigns an entry for the transaction in the deferred request queue for storing the token latched from the address bus. The assigned entry in the queue of the responding agent stores the token and the REQ, BE, and Address fields. After the transaction is complete, the responding agent becomes a request bus owner and initiates a second bus transaction to provide a deferred reply. The responding agent also reclaims free queue entries in the deferred request queue.
The requesting agents of the present invention include logic for managing the request pending queue and for token generation. Based on the above description, this logic is well within the ability of those skilled in the art, and thus, will not be described further. The responding agents also have logic for managing their queues. Preferably, the responding agent is able to take appropriate action on the new request of the bus while the deferred requests are being processed. The responding agent is further provided with the capability to compare the address of the new request against the address of an entry in the deferred request queue. In one embodiment, each agent includes sixteen 31-bit latches and sixteen 31-bit comparators to compare the address of the new request to addresses stored in the deferred request queue of the responding agent. The size of the comparators may be reduced, such that only the lower bits in the address are compared. On a positive match, the responding agent may abort the new request to avoid any conflict with an already deferred request.
In the present invention, the requesting agents are capable of accepting and comprehending the deferred responses (e.g., the deferral response and the deferred reply). In the present invention, the requesting agents are also capable of taking the appropriate action(s) in response to these responses. One action may involve temporarily suspending a request.
In one embodiment, the requesting agents assumes that every outstanding transaction issued in the Request Phase may receive a deferral response. Each requesting agent includes a queue to temporarily store deferred requests (e.g., tokens and their associated requests). Therefore, the requesting agents maintain an internal pending request queue with the same size as its ability to issue new requests. One embodiment of the pending request queue is shown in FIG. 7. Referring to
On observing a deferral response, the requesting agent maintains a copy of the token provided with the request in the generated token field 702 in outstanding transaction queue 700. The requesting agents also have the ability to release the bus after it received deferral response.
In one embodiment, a separate request pending queue is not required when the bus agent already includes a register file or list of bus operations that are pending. Since the agent ID is common to all queue entries, only a storage area specifying the pending transactions is required. The In-order queue, or other memory storage, that maintains a record of operations for the bus can be used as a pending request queue. Each of the transactions are identified using an index (e.g., 0,1,2,3). In one embodiment, only two bits are used to support index values for four possible pending transactions. A field for one or more bits may be added to the queue and used to indicate whether a request received a deferral response. Therefore, a separate request pending queue is not required. Note that token generation logic would have to obtain an agent's ID from a storage location and combine it with the request identifier (e.g., index into a bus queue) to generate a token.
The requesting agent also includes matching hardware for matching the subsequently returned data or completion signals to the appropriate request using the returned token. During the second independent transaction, the requesting agent matches the resent token with all stored tokens in its pending request queue. On an ID match, the requesting agent can complete the operation and discard the original suspended request from its pending request queue.
In one embodiment, each requesting agent includes comparator logic to perform the matching. In one embodiment, the comparator logic is comprised of 8-bit comparators for performing the matching and control logic for identifying the match and returning data to internal units with their interval tags. In another embodiment, separate agent ID and transaction ID (e.g., index) matching logic is used. One embodiment of the matching hardware for matching a transaction ID is shown in FIG. 8. Note that agent ID matching logic, such as described in
In one embodiment, latch 801 comprises a 4-bit latch which receives the transaction ID from the resent token from the address bus. Latch 801 is sized according to the number of bits in the transaction ID of the resent token. Latch 801 supplies the transaction ID to each of comparators 806-809. Each of the tokens stored in the pending request queue of the requesting agent are supplied to the comparators 806-809 via latches 802-805. Latches 802-805 are sized according to the number of bits in the transaction ID of tokens.
After performing an agent ID match, each of comparators 806-809 compares the transaction ID of the resent token to those of the stored tokens. If there is a match to a token stored in the pending request queue, one of comparators 806-809 produces a high output. If there is not a match to a token stored in the pending request queue, none of comparators 806-809 produces a high output. If none of the outputs from comparators 806-809 is high, then the No Match output of NOR gate logic 810 is high, thereby indicating that the resent token does not correspond to a suspended request in the requesting agent. If one output from comparators 806-809 is high, then the match output of NOR gate logic 810 is high, thereby indicating that the resent token corresponds to a suspended request in the requesting agent. In case of a match, the requesting agent "wakes up" and latches the data on the data bus (optional) and receives the completion signals corresponding to the original request.
Note that latches and comparators large enough to accomodate the entire token (e.g., 8-bit comparators, latches) may be used. However, in view of the fact that the agent ID portion of the resent token is always the same, complexity and cost may be reduced by providing only one agent ID comparison with separate transaction ID comparisons.
If a separate request pending queue is not required (and an existing bus queue is used), the matching logic of the present invention matches the agent ID portion of the resent token with its ID and then uses the remainder of the returned token as an index into the queue.
In an alternative embodiment, the present invention could use the request address as part or all of the token. One embodiment of the token using the address is shown in FIG. 9. Referring to
One advantage in this embodiment is that it recognizes the fact that any token definition may be either too constraining or too expensive due to different requirements of specific applications. When a new token definition is made, the number of bits in the token definition must be fixed. Depending on the scheme chosen, this, in turn, limits both the number of request/response agents that can be supported on the bus and the number of requests that can be supported per agent. Regardless of the scheme chosen for some specific application, it may not be too constraining. Thus, using an address as a token would mean that no artificial limitations are introduced. Secondly, the use of no token takes into account the fact that for highest performance, a full address comparison is desired for a new request with all the entries in the pending request queue of the requesting agent. This is in addition to the token matching required for the deferred replies generated by the responding agents. The present invention does add complexity.
By using the address as a token, the original requesting agent simply snoops on the address and compares it with its internal pending request queue. The response-initiated bus transaction is performed in the same manner with the exception of clearly marking the address as returning from a deferred response. This allows the proper differentiation between deferred replies and normal requests.
The responding agents maintain an internal deferred request queue similar to that shown in FIG. 6. One embodiment of the deferred request queue is shown in FIG. 10. Referring to
In this embodiment, the requesting agent is responsible for releasing the bus after receipt of a deferral response. Using the address as a token, the requesting agents still maintains an internal pending request queue with the same size as its ability to issue new requests.
The requesting agent also includes matching hardware for matching the subsequently returned data and/or completion signals to the appropriate request using the subsequently returned address. During the second independent transaction, the requesting agent matches the resent address (e.g., the token) with all tokens in its pending request queue. On an address match, the requesting agent can discard the original request from its pending request queue and complete the operation. In this embodiment, the requesting agent uses 54-bit latches and a 54-bit comparator per latch to perform the matching. In one embodiment, the comparator logic includes control logic for identifying the match and returning data to internal units with their internal tags.
When the address is used as the token, the requesting agent does not need to generate a token. The responding agent arbitrates for the bus and runs a bus transaction with the requested data and the original address. In one embodiment, the responding agent includes a 36-bit address plus 10-bit request bus driver to facilitate the sending of the address.
Note that this embodiment is advantageous in that no new pins or token specifications are required. Note also that in this embodiment, the requesting agents still have the overhead of full 36-bit address plus 10-bit request comparison. This logic overhead may be acceptable for both the processor and a caching I/O bridge where the existing snooping logic can be reused.
Exemplary Applications of the Present Invention by the Processor and Various Controllers
The processor of the present invention performs speculative and out-of-order execution. This implies that the microengine of the processor continues execution beyond missing data references. After the access is verified as a miss within the cache memory of the processor and the backside cache memory, the request is sent to the processor-memory bus. A long latency access can be optimally satisfied by returning a deferral response to the processor to free up the bus. In this manner, the processor can continue additional data transfers.
The deferred transaction capability of the processor-memory bus can be exploited by the external subsystems. For instance, the L3 cache may return a deferred response on a cache miss and a normal in order response on a cache hit. The L3 cache controller continues to access externally and completes the request with a second independent transaction after the data is received. In the meantime, the processor-to-L3 cache memory data transfers continue. Thus, the deferred response mechanism of the present invention allows for non-blocking components to be implemented between the processor and a processor-memory (e.g., system) bus.
The present invention also is advantageous to any access from the processor to the I/O bridge. Because accesses from the processor to the I/O bridge would involve a long latency as compared with other memory elements directly resident on the system bus, all I/O bridge accesses from the processor may be given a deferral response resulting in a substantial improvement in available processor bandwidth.
In the present invention, a bus transaction occurs in a normal pipelined manner with addresses being driven onto the address bus and data being returned on the data bus. When a deferred bus transaction occurs, a deferred reply may be generated. The present invention reuses the existing bus architecture to indicate that the access is a deferred type of access. In other words, in the present invention, when a responding agent prefers to not respond to its request in a pipelined manner, a deferral response is made and the responding agent latches a token sent by the requesting agent. In this manner, the token maintains the relationship between the requesting agent and the responding agent. When a requesting agent is waiting for a normal response, the requesting agent recognizes that the responding agent has returned a deferral response, as opposed to a normal response. Thus, by allowing the token to be sent on the address bus, no additional hardware, such as a separate token bus, is required. In this manner, the present invention allows for deferred transactions to occur without any increase in the number of pins. In fact, because separate token buses are not required for the request and response paths, the present invention reduces the number of pins required by each package to perform deferred bus transactions.
In the present invention, the responsibility for token management is placed on both the requesting agent and the responding agent. The requesting agent is responsible for supplying the token, while the responding agent is responsible for supplying the deferred reply at the appropriate time. In the present invention, only those units designed to use the token use them. The computer system could include other response agents, such as a memory controller, which only produce in-order response and to not create deferred responses. These "in-order" agents always return completion signals and/or data in a pipelined manner. Thus, the present invention allows design of simpler in-order response agents with zero logic burden in the presence of other agents capable of generating deferred responses.
Whereas many alterations and modifications of the present invention will no doubt become apparent to a person of ordinary skill in the art after having read the foregoing description, it is to be understood that the particular embodiment shown and described by way of illustration is in no way intended to be considered limiting. Therefore, references to details of the preferred embodiment are not intended to limit the scope of the claims which in themselves recite only those features regarded as essential to the invention.
Thus, a method and apparatus for performing deferred bus transactions in a computer system has been described.
Pawlowski, Stephen S., Sarangdhar, Nitin V., Singh, Gurbir, MacWilliams, Peter D., Rhodehamel, Michael W., Lai, Konrad K.
| Patent | Priority | Assignee | Title |
| 6813767, | Jun 30 2000 | Intel Corporation | Prioritizing transaction requests with a delayed transaction reservation buffer |
| 7469308, | Feb 19 2002 | Nvidia Corporation | Hierarchical bus structure and memory access protocol for multiprocessor systems |
| 7779188, | Mar 22 2005 | Intel Corporation | System and method to reduce memory latency in microprocessor systems connected with a bus |
| 7840778, | Feb 19 2002 | Nvidia Corporation | Processor cluster architecture and associated parallel processing methods |
| 8015379, | Feb 01 2008 | International Business Machines Corporation | Wake-and-go mechanism with exclusive system bus response |
| 8082315, | Apr 16 2009 | International Business Machines Corporation | Programming idiom accelerator for remote update |
| 8127080, | Feb 01 2008 | International Business Machines Corporation | Wake-and-go mechanism with system address bus transaction master |
| 8145723, | Apr 16 2009 | International Business Machines Corporation | Complex remote update programming idiom accelerator |
| 8145849, | Feb 01 2008 | International Business Machines Corporation | Wake-and-go mechanism with system bus response |
| 8171476, | Feb 01 2008 | International Business Machines Corporation | Wake-and-go mechanism with prioritization of threads |
| 8190803, | Feb 19 2002 | Nvidia Corporation | Hierarchical bus structure and memory access protocol for multiprocessor systems |
| 8225120, | Feb 01 2008 | International Business Machines Corporation | Wake-and-go mechanism with data exclusivity |
| 8230201, | Apr 16 2009 | International Business Machines Corporation | Migrating sleeping and waking threads between wake-and-go mechanisms in a multiple processor data processing system |
| 8250396, | Feb 01 2008 | International Business Machines Corporation | Hardware wake-and-go mechanism for a data processing system |
| 8312458, | Feb 01 2008 | International Business Machines Corporation | Central repository for wake-and-go mechanism |
| 8316218, | Feb 01 2008 | International Business Machines Corporation | Look-ahead wake-and-go engine with speculative execution |
| 8341635, | Feb 01 2008 | International Business Machines Corporation | Hardware wake-and-go mechanism with look-ahead polling |
| 8386822, | Feb 01 2008 | International Business Machines Corporation | Wake-and-go mechanism with data monitoring |
| 8452947, | Feb 01 2008 | International Business Machines Corporation | Hardware wake-and-go mechanism and content addressable memory with instruction pre-fetch look-ahead to detect programming idioms |
| 8489857, | Feb 19 2002 | Nvidia Corporation | Processor cluster architecture and associated parallel processing methods |
| 8516484, | Feb 01 2008 | International Business Machines Corporation | Wake-and-go mechanism for a data processing system |
| 8612977, | Feb 01 2008 | International Business Machines Corporation | Wake-and-go mechanism with software save of thread state |
| 8640141, | Feb 01 2008 | International Business Machines Corporation | Wake-and-go mechanism with hardware private array |
| 8640142, | Feb 01 2008 | International Business Machines Corporation | Wake-and-go mechanism with dynamic allocation in hardware private array |
| 8725992, | Feb 01 2008 | International Business Machines Corporation | Programming language exposing idiom calls to a programming idiom accelerator |
| 8732683, | Feb 01 2008 | International Business Machines Corporation | Compiler providing idiom to idiom accelerator |
| 8788795, | Feb 01 2008 | International Business Machines Corporation | Programming idiom accelerator to examine pre-fetched instruction streams for multiple processors |
| 8880853, | Feb 01 2008 | International Business Machines Corporation | CAM-based wake-and-go snooping engine for waking a thread put to sleep for spinning on a target address lock |
| 8886919, | Apr 16 2009 | International Business Machines Corporation | Remote update programming idiom accelerator with allocated processor resources |
| Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
| Jun 14 2001 | Intel Corporation | (assignment on the face of the patent) | / |
| Date | Maintenance Fee Events |
| Sep 15 2005 | ASPN: Payor Number Assigned. |
| Feb 09 2007 | M1552: Payment of Maintenance Fee, 8th Year, Large Entity. |
| Feb 03 2011 | M1553: Payment of Maintenance Fee, 12th Year, Large Entity. |
| Date | Maintenance Schedule |
| Jan 13 2007 | 4 years fee payment window open |
| Jul 13 2007 | 6 months grace period start (w surcharge) |
| Jan 13 2008 | patent expiry (for year 4) |
| Jan 13 2010 | 2 years to revive unintentionally abandoned end. (for year 4) |
| Jan 13 2011 | 8 years fee payment window open |
| Jul 13 2011 | 6 months grace period start (w surcharge) |
| Jan 13 2012 | patent expiry (for year 8) |
| Jan 13 2014 | 2 years to revive unintentionally abandoned end. (for year 8) |
| Jan 13 2015 | 12 years fee payment window open |
| Jul 13 2015 | 6 months grace period start (w surcharge) |
| Jan 13 2016 | patent expiry (for year 12) |
| Jan 13 2018 | 2 years to revive unintentionally abandoned end. (for year 12) |