Patent Application
20050050253
In computer systems, devices may communicate with each other over one or more shared buses. To avoid conflicts that would occur if more than one device attempted to communicate over a bus at the same time, various arbitration schemes may be generally used to assign use of the bus to only one device at a time. In the round-robin technique, each device in turn is given the chance to use the bus in a continuing, rotating fashion. Over time, every device may therefore have equal access to the bus, but at any given time, any device might have to wait for the bus until that device's turn comes. This is a disadvantage for a device that has a need to access the bus quickly, if another device that could have waited is granted access first. Even if only one device is requesting the bus, that device may have to wait until its turn. The round-robin technique may not be suited for time-critical data transfers in which data may be lost if it is not transferred within a particular time frame.
In the hierarchical technique, the devices are assigned rankings. If two or more devices are requesting the bus at the same time, the higher-ranking device is granted access. While this may improve performance for time-critical devices, it may also result in a condition called starvation, in which a lower-ranking device is repeatedly denied access to the bus because higher-ranking devices consume all the available bus time.
The shortcomings of these techniques are further aggravated by the fact that the optimum priorities among the devices, and therefore the relative advantages/disadvantages of a particular technique, may change within a system when different applications are run, and may even change dynamically as the same applications run.
The invention may be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention. In the drawings:
In the following description, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques may not be shown in detail in order not to obscure an understanding of this description.
References to “one embodiment”, “an embodiment”, “example embodiment”, “various embodiments”, etc., indicate that the embodiment(s) of the invention so described may include a particular feature, structure, or characteristic, but not every embodiment necessarily includes the particular feature, structure, or characteristic. Further, repeated use of the phrase “in one embodiment” does not necessarily refer to the same embodiment, although it may.
Some embodiments of the invention may use a combination of some or all of ranking, age since the bus was first requested, retry status, order of connection, etc., to grant bus access to one of the requesters. Some of the techniques used may be programmable on-the-fly as the system operates.
A client may be a physical device and/or a circuit that transfers data over the bus 110, where data may include a command, status, information, etc. Examples of clients may include, but are not limited to, such things as a disk controller, a bus bridge, a graphics accelerator, a memory, etc. Within the context of this description, signals that are only used to facilitate the transfer (e.g., bus clock, device address, data enable, etc.) are not considered data, even though they may be necessary for the transfer of data. Transferring data may include transmitting data, receiving data, or both.
In the illustrated embodiment a single bus 110 is shown connecting processor interface 160, memory controller 150, arbiter 140, and clients 121-123, 131-132, but in other embodiments these connections may be made through multiple buses and/or through other circuitry not shown. In one embodiment the bus 110 is a split-transaction bus, but other types of buses may also be used. A split-transaction bus may comprise a bus using split-transaction data transfer protocol, in which the target client arbitrates for, and obtains control of, the bus before sending the response requested by the master client, and in which other bus transactions involving other clients may take place over the bus between the command from the master client and the response from the target client. Thus a single data transfer sequence may be split into at least two separate bus transactions.
Arbiter 140 may be used to allocate control of the bus to various clients that request use of the bus to perform bus transactions. Request channels 102, 103 are shown coupling each client to the arbiter 140, where a request channel may convey a bus request from a client to the arbiter, and may also convey a grant of the bus from the arbiter to the requesting client, although the scope of the present invention is not limited in the respect. Bus requests and bus grants may be handled in various ways. In the illustrated embodiment, a separate request channel 102 is shown from each master client 121-123 to the arbiter 140, while a separate request channel 103 is shown from each target client 131, 132 to the arbiter 140. Other embodiments may use other techniques to convey bus requests from clients to the arbiter. For example: 1) all request channels may be identical, regardless of the nature of the client, 2) a common bus may be used to convey bus requests from multiple clients and convey bus grants to multiple clients, 3) the request channels may be part of bus 110, 4) the requests and grants may be handled through different techniques, 5) any combination of these techniques, 6) etc. Various techniques for conveying bus requests and bus grants between clients and an arbiter are known and are not discussed in detail herein to avoid obscuring an understanding of the various embodiments of the invention.
In one embodiment, arbiter 140 may be coupled to bus 110 so that portions of arbiter 140 may be programmed by processor 165, which may be coupled to arbiter 140 through processor interface 160 and bus 110. Processor interface 160 may, in turn, be comprised of any feasible combination of circuitry, buses, bridges and other components. Bus 110 may also be coupled to memory 155 through memory controller 150. Memory controller 150 may also be comprised of any feasible combination of circuitry, buses, bridges and other components. Memory 155 may utilize any feasible volatile or non-volatile technology that is currently existing or yet to be developed, for example, static random access memory (RAM), dynamic RAM, flash, magnetic, etc. In some embodiments, one or both of processor 165 and memory 155 may be clients whose bus requests are arbitrated by arbiter 140.
In the illustrated embodiment, master client arbitration logic 220 may perform arbitration for requests received from master clients, while target client arbitration logic 240 may perform arbitration for requests received from target clients. Client class arbitration logic 230 may determine which of arbitration logics 220, 240 will be able to perform arbitration at the present time (e.g., whether only master client requests or only target client requests will be considered during the current arbitration). In a particular embodiment, arbitration logics 220, 230, 240 may be standardized for the arbitration algorithms used, while arbitration interface 210 and/or bus interface 250 may be customized for the type of bus being used, thus permitting a single arbitration logic design to be easily adapted for multiple types of buses. Each of arbitration logics 220, 230, 240 may be implemented in various ways, such as discrete logic, one or more state machines, firmware, etc. Any or all of arbitration logics 220, 230, 240 and interfaces 210, 250 may be scalable to accommodate systems of various sizes and capacities.
If processing moves to 320, round-robin arbitration may be used. If multiple target clients are requesting the bus, at 321 the next target client in the round-robin process that is requesting the bus is selected as the ‘winner’, i.e., the target client that is granted access to the bus. If only one target client is requesting the bus, then that target client may be granted the bus. The process of actually granting the bus (i.e., informing the requesting client that it may now use the bus) is not shown, but may be assumed to follow from each of blocks 321 (
If all requesting clients are master clients, or if some of the requesting clients are master clients and it is the master clients' turn at decision block 310, processing may continue at ‘A’ in
1) Bus lock—some bus protocols, such as the PCI-X bus protocol, allow a master client to take exclusive control of the bus until the lock condition is released. Under this condition, any competing clients may be denied access to the bus until the lock condition is released.
2) Sleep entry—during various types of sleep or standby modes, access to the bus may be restricted to some or all requesting clients. Such restricted access may take various forms, depending on the bus and the specific requirements of the system and the sleep protocols.
3) Lock-Out—To improve bus performance when retries are used, if a first master client tries to access a target that has a pending RETRY to a second master client, the first master client may be locked-out of the bus as long as the RETRY transaction is pending.
If no special conditions exist at 330, it may next be determined at 350 if any of the pending bus requests are retry requests. If only one of the pending requests is a retry request, that request may be determined the winner at 351. If there are no pending retry requests, processing may move to 360 to further consider all the pending requests from master clients. If multiple pending requests are retry requests, processing may move to 360 to further consider only those retry requests.
At 360 it is determined which of the pending requests being considered have the highest ranking in a hierarchical priority structure that assigns relative ranking to the various clients. If only one pending request has the highest ranking, that request may be determined the winner at 361, and the bus may be granted to the associated client. However, if multiple pending requests have the highest ranking, processing may move to 370 to further consider only those requests with the highest ranking. This situation may occur if the ranking values represent ‘levels’ of rank, and multiple clients (or their associated requests) may occupy the same level in the hierarchy.
At 370 it is determined which of the pending requests being considered have the greatest age. Age may be determined in various ways. For example, in one embodiment age may be measured as an indication of the number of clock cycles that have passed since the initial request was originally received, which may correspond to elapsed time. In another embodiment, age may be measured as the number of bus requests that have been granted to other clients since the request was initially received. In still another embodiment, age may be measured as the number of retries that have been made by the client since the initial request was received. Various other measures of age may also be used. If a single request is determined to have the greatest age, the associated client may be determined the winner at 371. If multiple requests are determined to have the same greatest age, processing may pass to 380 to further consider only those requests with the greatest age.
At 380, if there are still multiple requests being considered, a final arbitration made be made based on order of hook-up. Order of hook-up may be defined in various ways. For example, in one embodiment order of hook-up may be defined by relative bus addresses that are assigned at the time each client device is physically connected to the bus, by physical addresses that are hard-wired into the devices, by the physical location of the client devices on the bus, etc. Since order of hook-up, however defined, results in a strict hierarchy of clients, a single winner should be determined at this stage, and a single winner determined at 381.
When a single winner is determined at any feasible portion of the process of the flow chart of
In another embodiment, arbiter 140 may have its own dedicated bus interface 250 as shown in
The foregoing description is intended to be illustrative and not limiting. Variations will occur to those of skill in the art. Those variations are intended to be included in the various embodiments of the invention, which are limited only by the spirit and scope of the appended claims.
