U.S. patent application number 12/475134 was filed with the patent office on 2009-12-17 for method and system for controlling bus access.
This patent application is currently assigned to Advanced Micro Devices, Inc.. Invention is credited to Zohair Hyder, Warren Kruger, Elene Terry, Xidong Wang.
Application Number | 20090313323 12/475134 |
Document ID | / |
Family ID | 41415760 |
Filed Date | 2009-12-17 |
United States Patent
Application |
20090313323 |
Kind Code |
A1 |
Kruger; Warren ; et
al. |
December 17, 2009 |
Method and System for Controlling Bus Access
Abstract
A system and method for controlling communications between a
plurality of clients and a central component. An embodiment of the
invention includes one or more buses that connect the clients and
the central component. This embodiment also includes a control
module that is configured to receive ASK messages from the clients
and issue GO commands to the clients. Each ASK message represents a
request from a client to access the central component. Each GO
command to the client represents permission for that client to
access the central component. The control module comprises delay
stages that delay the GO command. The delays may be different from
client to client. The number of delay stages is chosen so that for
all clients, the delay between the issuance of a GO command and the
receipt at the central component of communications from the clients
is the same.
Inventors: |
Kruger; Warren; (Sunnyvale,
CA) ; Hyder; Zohair; (Fremont, CA) ; Terry;
Elene; (Los Altos, CA) ; Wang; Xidong;
(Sunnyvale, CA) |
Correspondence
Address: |
STERNE, KESSLER, GOLDSTEIN & FOX P.L.L.C.
1100 NEW YORK AVENUE, N.W.
WASHINGTON
DC
20005
US
|
Assignee: |
Advanced Micro Devices,
Inc.
Sunnyvale
CA
|
Family ID: |
41415760 |
Appl. No.: |
12/475134 |
Filed: |
May 29, 2009 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61071990 |
May 29, 2008 |
|
|
|
Current U.S.
Class: |
709/203 |
Current CPC
Class: |
G06F 13/387
20130101 |
Class at
Publication: |
709/203 |
International
Class: |
G06F 15/16 20060101
G06F015/16 |
Claims
1. A system for controlling communications between a plurality of
clients and a component, comprising: a control module configured to
receive ASK messages from the clients and issue respective
corresponding GO commands to the clients, wherein each ASK message
represents a request from a client to access the component and each
GO command to the client represents permission to access the
component, wherein the control module comprises a configurable
number of delay stages so that for each client, the delay between
issuance of a GO command and receipt, at the component, of
communications from the client is the same.
2. The system of claim 1, wherein the component comprises a memory
device.
3. The system of claim 1, wherein said control module comprises a
memory controller.
4. The system of claim 1, wherein the clients comprise at least one
of: (a) a color buffer; (b) a depth buffer; (c) a texture cache;
(d) a multimedia client; and (e) a display.
5. The system of claim 1, further comprising a bus system of one or
more buses configured to convey the communications between the
clients and the component.
6. The system of claim 1, further comprising a point-to-point
connection configured to convey the communications between one of
the clients and the component.
7. The system of claim 1, further comprising a tree structure
communications topology configured to convey the communications
between the clients and the component.
8. The system of claim 1, further comprising a daisy chain
communications topology configured to convey the communications
between the clients and the component.
9. The system of claim 1, wherein said control module is further
configured to monitor future time slots at which GO commands may be
issued and, if a future time slot is vacant, advancing a next GO
command to said vacant future time slot.
10. The system of claim 1, wherein said control module is further
configured to create one or more of said delay stages to be added
for subsequent GO commands for said client.
11. The system of claim 10, further comprising a bus system,
wherein said control module is further configured to: clear the bus
system when a client first sends an ASK message to said control
module; send a GO command to said client; monitor the time that
elapses between issuance of said GO command and receipt at the
component of communications from said client; calculate a
difference between a maximum delay and said elapsed time; and use
said difference to create said delay stages to be added for
subsequent GO commands for said client.
12. The system of claim 10, wherein said control module is further
configured to create said delay stages for GO commands for a
client, such that the resulting total time between issuance of a GO
command to the client and receipt at the component of
communications from the client is equal to a predefined time.
13. The system of claim 1, further comprising a communications
topology that conveys said communications from the clients to said
component, wherein said topology comprises one or more branch nodes
configured to: send an ASK message to said control module; receive
a corresponding GO command; and send a dummy transmission to said
control module, wherein said control module determines a delay over
said communications topology on the basis of a transit time of said
dummy transmission.
14. A method for controlling communications between a plurality of
clients and a component, comprising: (a) determining a maximum
delay, among all clients, between issuance of a GO command to a
client and receipt at the component of communications from the
client, wherein the GO command grants permission to the client to
send to the communication to the component over a communications
topology; (b) for each client, determining any additional delay to
be added between the issuance of the GO command and receipt at the
component of communication from the client, wherein the additional
delay for each client equalizes, for all clients, the total delay
between the issuance of the GO command and receipt at the component
of communication.
15. The method of claim 14, wherein said step (a) comprises
arbitrarily choosing the maximum delay.
16. The method of claim 14, wherein said step (b) comprises, for
each client: (i) receiving a first ASK message from the client,
wherein the ASK message represents a request to access the central
component; (ii) clearing out the communications topology that
connects the client with the component; (iii) sending a GO command
to the client and simultaneously starting a counter; (iv) stopping
the counter when communication from the client has reached the
component; and (v) determining the difference between the maximum
delay and the counter, wherein the difference is the delay to be
added.
17. The method of claim 14, wherein said communications topology
comprises at least one branch node, and wherein said step (a)
comprises: (i) receiving an ASK message from a branch node at the
control module; (ii) sending a GO command corresponding to the ASK
message; (iii) receiving a dummy transmission from the branch node
at the control module; and (iv) determining the maximum delay on
the basis of a transit time of said dummy transmission.
18. The method of claim 14, wherein said communications topology
comprises a bus system of one or more buses.
19. The method of claim 18, wherein said bus system comprises a
daisy chain of buses.
20. The method of claim 18, wherein said bus system comprises a
tree structure of buses.
21. The method of claim 14, wherein said communications topology
comprises a point-to-point connection between one of the clients
and the component.
22. The method of claim 14, wherein the component comprises a
memory device.
23. The method of claim 14, wherein the plurality of clients
comprises at least one of: (a) a color buffer; (b) a depth buffer;
(c) a texture cache; (d) a multimedia client; and (e) a
display.
24. The method of claim 14, further comprising: (c) observing
future time slots that can be used for issuance of future GO
commands, to see if any future time slot is available; and (d) if
so, advancing a GO command for a next client to the available time
slot.
25. A computer program product comprising a computer useable medium
having control logic stored therein for controlling communications
between a plurality of clients and a component, the computer
control logic comprising: first computer readable program code
means for receiving ASK messages from the clients and issuing
respective corresponding GO commands to the clients, wherein each
ASK message represents a request from a client to access the
central component and each GO command to the client represents
permission to access the component, wherein the first computer
readable program code means is configured to implement a
configurable number of delay stages so that for each client, the
delay between issuance of a GO command and receipt of the GO
command at the component of communications from the client is the
same.
26. The computer program product of claim 25, wherein the first
computer readable code means is configured to adapt a processor to
receive the ASK messages from the clients and issue the respective
corresponding GO commands to the clients, wherein the first
computer readable program code means further adapt the processor to
implement the delay stages.
27. The computer program product of claim 25, wherein the computer
program code means comprise HDL instructions.
28. The computer program product of claim 27, wherein the HDL
instructions, when processed, are adapted to be used to manufacture
a processor capable of receiving the ASK messages from the clients
and issuing the respective corresponding GO commands to the
clients, wherein the processor implements the delay stages.
Description
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] The present application claims the benefit of U.S.
Provisional Patent Application No. 61/071,990, filed on May 29,
2008, entitled "Method and System for Controlling Bus Access",
which is incorporated herein by reference in its entirety.
BACKGROUND OF THE INVENTION
[0002] 1. Field of the Invention
[0003] The invention described herein relates to communication
between clients and a single component or resource.
[0004] 2. Background Art
[0005] In digital circuit design, it is a common problem to have a
single component that must be accessed by a number of clients. For
example, a single memory device, such as a dynamic random access
memory (DRAM), may provide memory resources for a number of
clients. If the clients are not readily scheduled, or activity
between clients and the single component is not otherwise
controlled, then access to the component can be hampered by
contention problems.
[0006] A number of solutions can be used to provide access to a
single component, but many have shortcomings. To allow several
clients to communicate with a single component, each client may be
given its own physical channel to the single component. This might
entail separate wiring between each client and the single
component. This, however, represents an expensive solution. If
implemented on an integrated circuit or in a printed circuit board,
this requires significant area. Nor does this solve the problem of
contention. Even if each client has its own physical channel to the
single component, problems can arise when more than one client
needs to access the component more or less simultaneously.
[0007] Another solution would be the use of a bus. Here, each
client would need connectivity to the bus. Likewise, the single
component would be connected to the bus. This addresses the problem
of excessive wiring. The bus, however, now represents another
resource, access which must be managed. Contention problems can
arise when one or more clients seek to access the bus at the same
time. Allocation of access to the bus can be managed through any of
several well known algorithms. Access by clients to the bus may be
based, for example, on a round robin process. Such algorithms,
however, can be inflexible. There may be situations where one
client has no need for the bus, while another client needs a large
amount of bandwidth. Such conditions are not readily handled by a
traditional bandwidth allocation processes. As a result,
communications through a bus can be slow and inflexible. Moreover,
the bus must be engineered to allow for the maximum amount of
demand that the designer can envision. This allows the bus to
service peak demands. Often, however, peak demand is not typical.
More often, the requirements on the bus are well below the peak
level. As a result, bus capacity will be wasted most of the
time.
[0008] Another method for addressing the problem of providing
access to a single component from multiple clients is the use of a
daisy chain protocol. Here, given a number of clients that need to
access a component, arbitration is provided to decide the client
that will ultimately be given access to the component. A first and
second client may need to access the component, in which case
arbitration will decide which of the two clients remains in
contention for the component. The winner among those two clients is
then placed in competition with a third contending client.
Arbitration is then provided between the third client and the
survivor of the first arbitration. Again, a single surviving will
be chosen. This survivor will then be put in contention with a
fourth client. Again arbitration will be provided. This process is
continued so that all clients are given an opportunity to contend
for the access to the component.
[0009] Such a protocol, however, requires significant overhead. For
example, in a situation where each client is seeking to store data
at the single component, there needs to be space for temporary
storage, while the data is stalled during arbitration. Moreover,
there are issues as to the fairness of the outcome. At any given
decision point in the process, for example, it is not known what
requests from clients have been handled through arbitration
previously, and what needs are yet to be considered later in the
process. The process is essentially ignorant of past and future
needs. This could be handled by reserving a time slot
isochronously, but in the event that such a reserved slot is never
used, the reservation represents a waste of bandwidth. This leads
to lost efficiency.
[0010] There is a need, therefore, for a system and method that
allows a number of clients to access a single component in such a
way that minimizes wiring cost, and allows for fair and flexible
access to the component.
BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES
[0011] FIG. 1 is a block diagram illustrating the structure of an
embodiment of the invention.
[0012] FIG. 2 is a flowchart illustrating the overall processing of
an embodiment of the invention.
[0013] FIG. 3 is a flowchart illustrating initialization of the
process of the invention, according to an embodiment thereof.
[0014] FIG. 4 is a flowchart illustrating an alternative embodiment
of the initialization process.
[0015] FIG. 5 is a flowchart illustrating an embodiment of the
invention in which clients contending for access to the component
can take advantage of available bandwidth.
[0016] Further embodiments, features, and advantages of the present
invention, as well as the operation of the various embodiments of
the present invention, are described below with reference to the
accompanying drawings.
DETAILED DESCRIPTION OF THE INVENTION
[0017] A preferred embodiment of the present invention is now
described with reference to the figures, where like reference
numbers indicate identical or functionally similar elements. Also
in the figures, the leftmost digit of each reference number
corresponds to the figure in which the reference number is first
used. While specific configurations and arrangements are discussed,
it should be understood that this is done for illustrative purposes
only. A person skilled in the relevant art will recognize that
other configurations and arrangements can be used without departing
from the spirit and scope of the invention. It will be apparent to
a person skilled in the relevant art that this invention can also
be employed in a variety of other systems and applications.
[0018] The invention described herein includes a system and method
for controlling communications between a plurality of clients and a
central component. An embodiment of the invention includes one or
more buses that connect the clients and the central component. This
embodiment also includes a control module that is configured to
receive ASK messages from the clients and issue GO commands to the
clients. Each ASK message represents a request from a client to
access the central component. Each GO command to the client
represents permission for that client to access the central
component. The control module comprises delay stages that delay the
GO command. The delays may be different from client to client. The
number of delay stages is chosen so that for all clients, the delay
between the issuance of a GO command and the receipt at the central
component of communications from the clients is the same.
[0019] Note that the concepts of the invention described herein can
be applied in a number of settings. Generally, the invention
addresses the problem in which multiple clients need to access a
single component. This problem may exist, for example, on a single
integrated circuit. Moreover, this problem may occur on a printed
circuit board, or on a back plane. In any of these settings, the
concepts of this invention can be used to address the problem of
providing access to multiple clients, all of whom may need to
access a single component.
[0020] FIG. 1 is a block diagram illustrating an embodiment of the
system of the invention. In FIG. 1, two clients are shown, client
110 and client 111. Both clients require access to a single
component (not shown). Both clients are also in communication with
a control module 115. In the illustrated embodiment, the clients
need access to a single component represented by a memory device,
such as a DRAM. The control module 115 is therefore shown as a
memory controller ("MC"). When either of clients 110 or 111 needs
to access the memory device, respective ASK messages are sent to
control module 115. The ASK messages are registered with respective
counters 120 and 121. The role of these counters will be described
in greater detail below. The ASK messages are then forwarded to an
arbiter 140. Arbiter 140 then issues respective GO commands to
clients 110 and 111. Each GO command serves to grant permission to
the respective client to send information to the memory device.
Arbiter 140 selects which client is to receive permission at any
particular time. The respective GO messages can therefore be sent
at different times, depending on the decision of the arbiter
140.
[0021] Note that with respect to client 111, the path of the GO
command from control module 115 to this client includes a delay
stage 131. Moreover, when client 111 transmits information to the
memory device, this takes the form of a SEND message, which
encounters a delay stage 141. Hence, there are two delays that
occur between the issuance of a GO command to client 111 and the
receipt, at the memory device, of a corresponding SEND message.
Generally, each client may have a different number of delays in the
loop between issuance of a GO command to the client and the
receipt, at the memory device, of a corresponding SEND message.
This complicates the problem of arbitration. In particular, GO
messages sent to different clients at different times may arrive at
the single component at the same time, creating a contention
issue.
[0022] To resolve this problem, additional delay stages can be
added to the loops of some of the clients. Generally, if delays are
added to the loop of each client, such that each loop consequently
has the same amount of total delay, the decision is simplified as
to when to issue GO commands for different clients. If a GO command
is then issued to a first client at time slot n, and a GO command
is issued to a second client at timeslot n+1, it is assured that
the SEND commands of these clients will arrive at the single
component at successive time slots. Contention is thereby
avoided.
[0023] In the embodiment of FIG. 1, the added delays are shown as
flip-flops 150 and 160. By adding two delays to the loop of client
110, this loop now has the same number of delays as the loop of
client 111.
[0024] The above embodiment shows two clients. In a real world
application, an arbitrary number of clients can be handled, given
the concept shown in FIG. 1. According to a process to be described
below, initially (before the addition of any delays) the maximum
delay is determined, among all clients, between the time of
issuance of a GO command and the receipt at the memory device of a
SEND message. This represents the longest preexisting loop, of all
the clients, between issuance of a GO command and receipt at the
memory device of the SEND message. One or more clients will have
such a maximum delay. The loops corresponding to the other clients
are then modified as necessary to include additional delays. For
each of the other clients and their loops, the added delays adjust
the total delay for the respective client to equal the maximum
delay.
[0025] Note also that the SEND messages are shown being sent
through a single request bus 170. Alternative embodiments of the
invention may use other communications topologies to connect
clients and the single component. For example, there may be more
than one bus. SEND messages may be conveyed to the single component
through a plurality of buses organized as a tree, or as a daisy
chain. Moreover, such buses may be organized as a tree of daisy
chains, or a daisy chain of trees, etc. Any such arrangement of
buses is referred to herein as a bus system. A bus system,
therefore, refers to any of several arrangements of buses,
including a single bus, or any combination of two or more buses. In
alternative embodiments, the communications topology between
clients and the single component includes a point-to-point
topology.
[0026] FIG. 2 illustrates the overall processing of the invention.
The process begins at step 210. In step 220, the maximum delay is
determined. As described above, the maximum delay results from
considering all of the clients, and the time delay involved for
each client between issuance of a GO command to the client and the
receipt of a SEND message from the client at the memory device or
other single component. The client having the longest delay is said
to have the maximum delay. In step 230, initialization is performed
for each client. This step will be described in greater detail
below.
[0027] Initialization includes the addition of delays to the path
between an arbiter and the client. As described above, such delays
are added to create a total delay for each client, where the total
delay equals the maximum delay.
[0028] In step 240, the actual operation (the sending of ASK
messages by clients, arbitration at the control module, issuance of
GO commands back to the clients, communication of SEND messages,
etc.) proceeds. The process concludes at step 250.
[0029] FIG. 3 illustrates an embodiment of the initialization step
230. The process begins at step 310. In step 320, the absolute
delay is determined for each client. This represents the time
between issuance of a GO command to the client and the receipt at
the single component of a SEND message from the client. In step
330, for each client the difference between the maximum delay and
the client's absolute delay is determined. This difference
represents the delay that is to be added for the client. In step
340, this delay to be added is stored for each client, and
implemented. The process ends at step 350.
[0030] FIG. 4 illustrates an alternative embodiment for
initialization step 230. The process begins at step 410. In step
420, a client requests to use the bus, i.e., sends an ASK message,
for the first time. In step 430, the control module clears out the
bus. This serves to avoid contention problems during
initialization. In step 440, the control module sends a GO message
to the client and at the same time starts a counter. In step 450,
the client transmits a SEND message. In step 460, the control
module detects when the SEND message reaches the single component,
and stops the counter at this point. The value in the counter
therefore represents the absolute delay for this client. In step
470, the memory controller calculates the difference between the
maximum delay and the absolute delay for this client. As described
above, this difference represents the delay to be added to the loop
for this client. The process concludes at step 480. The steps of
FIG. 4 are repeated for each client that seeks to use the single
component.
[0031] In other embodiments of the invention, alternative
mechanisms can be used to detect and measure the delay in the
communications topology between the client and the single
component. If the communications topology includes a bus, for
example, the spine of the bus may include branch nodes that perform
switching and power management functions. In addition, these branch
nodes may facilitate the process of measuring the delay between the
client and the single component, as follows.
[0032] In an embodiment of the invention, one or more branch nodes
sends an ASK message to the control module. The arbiter in the
control module responds by sending out a GO command to the branch
node(s). The branch node then sends out a dummy transmission over
the communications topology. When the dummy transmission is
received at the control module, the transit time required for the
dummy transmission is noted. This information can then be used to
calculate the maximum delay and/or the absolute delay for a
client.
[0033] In an alternative embodiment of the invention, a maximum
delay is not calculated per se. Rather, an arbitrary value is
chosen or predefined, where this predefined value is known to be
greater than or equal to the maximum delay. Delays are then added
for each client's path, so that each client has the same delay,
i.e., the predefined delay.
[0034] FIG. 5 illustrates a process through which a client can take
advantage of the fact that another client may be idle. The process
begins at step 510. In step 520, future time slots in which GO
commands can be issued are monitored at the control module. In this
step, therefore, the control device becomes aware of any future
time slots that are not allocated for the issuance of GO commands.
In step 530, a determination is made as to whether such future time
slots are available. If so, then a client's GO command (that may
have been scheduled for a later time slot) is advanced to the
available time slot. This allows another client (e.g., the next
client that would normally be issued a GO command after the vacant
time slot) to take advantage of the vacant time slot. The process
then returns to step 520. If, in step 530, no future time slots are
available, then the process returns to step 520.
Conclusion
[0035] It is to be appreciated that the Detailed Description
section, and not the Summary and Abstract sections, is intended to
be used to interpret the claims. The Summary and Abstract sections
may set forth one or more but not all exemplary embodiments of the
present invention as contemplated by the inventors, and thus, are
not intended to limit the present invention and the appended claims
in any way.
[0036] The present invention has been described above with the aid
of functional building blocks illustrating the implementation of
specified functions and relationships thereof. The boundaries of
these functional building blocks have been arbitrarily defined
herein for the convenience of the description. Alternate boundaries
can be defined so long as the specified functions and relationships
thereof are appropriately performed. For example, various aspects
of the present invention can be implemented by software, firmware,
hardware (or hardware represented by software such, as for example,
Verilog or hardware description language instructions), or a
combination thereof. Exemplary system 100 in which the present
invention, or portions thereof, can be implemented as
computer-readable code. After reading this description, it will
become apparent to a person skilled in the relevant art how to
implement the invention using other computer systems and/or
computer architectures.
[0037] Any apparatus or manufacture comprising a computer useable
or readable medium having control logic (software) stored therein
is referred to herein as a computer program product. It should be
noted that the operation, simulation, synthesis and/or manufacture
of the various embodiments of this invention may be accomplished,
in part, through the use of computer readable code, including
general programming languages (such as C or C++), hardware
description languages (HDL) including Verilog HDL, VHDL, Altera HDL
(AHDL) and so on, or other available programming and/or schematic
capture tools (such as circuit capture tools). This computer
readable code can be disposed in any known computer usable medium
including semiconductor, magnetic disk, optical disk (such as
CD-ROM, DVD-ROM). Control logic can also be embodied as a computer
data signal embodied in a computer usable (e.g., readable)
transmission medium (such as a carrier wave or any other medium
including digital, optical, or analog-based medium). As such, the
control logic can be transmitted over communication networks
including the Internet and internets. It is understood that the
functions accomplished and/or structure provided by the systems and
techniques described above can be represented in a core (such as a
GPU core) that is embodied in program code and may be transformed
to hardware as part of the production of integrated circuits.
[0038] The foregoing description of the specific embodiments will
so fully reveal the general nature of the invention that others
can, by applying knowledge within the skill of the art, readily
modify and/or adapt for various applications such specific
embodiments, without undue experimentation, without departing from
the general concept of the present invention. Therefore, such
adaptations and modifications are intended to be within the meaning
and range of equivalents of the disclosed embodiments, based on the
teaching and guidance presented herein. It is to be understood that
the phraseology or terminology herein is for the purpose of
description and not of limitation, such that the terminology or
phraseology of the present specification is to be interpreted by
the skilled artisan in light of the teachings and guidance.
[0039] The breadth and scope of the present invention should not be
limited by any of the above-described exemplary embodiments, but
should be defined only in accordance with the following claims and
their equivalents.
* * * * *