Electrical computers and digital data processing systems: input/ – Intrasystem connection – Bus interface architecture
Reexamination Certificate
2000-09-26
2003-12-02
Myers, Paul R. (Department: 2181)
Electrical computers and digital data processing systems: input/
Intrasystem connection
Bus interface architecture
C710S308000, C710S309000, C710S313000
Reexamination Certificate
active
06658520
ABSTRACT:
BACKGROUND
FIELD
This invention relates to information busses, and more specifically to insuring the coherency of independent busses.
BACKGROUND
Most processing systems have, at a minimum, basic building block units of a processing unit, memory, and Input/Output (I/O) devices. Some may also include a memory controller that provides decode and control functions for accesses to and from memory. The I/O devices may be managed by an input/output (I/O) controller. An I/O controller is useful when there are multiple I/O devices of various types. Generally, only one I/O device, or other device, may access memory at a time.
FIG. 1
shows a block diagram of an example computing system. The computing system includes a memory controller
10
, graphics device
12
(e.g., display), processing unit
14
, memory device(s)
16
, and I/O controller
18
. Memory controller
10
includes a memory
22
for buffering data between graphics device
12
and memory
16
, a memory
24
for buffering data between I/O controller
18
and memory
16
, and a controller
11
that manages data written to and read from memory
16
. Memories
22
and
24
may be first-in/first-out (FIFO) memories. I/O controller
18
includes a memory
25
that buffers data between memory controller
10
and I/O controller
18
, a Peripheral Component Interconnect (PCI) interface
32
that interfaces to a PCI bus
34
, and direct memory access (DMA) controllers
26
,
28
,
30
and
31
that control various I/O devices. Memory controller
10
and I/O controller
18
are connected by bus
20
.
In the system architecture shown in
FIG. 1
, if software (in processing unit
14
) needs to configure a DMA controller device (e.g., Universal Serial Bus (USB), Integrated Drive Electronics (IDE)) which is a legacy DMA controller, the software will send out a configuration cycle through bus
20
, target the DMA controller device, and have the cycle return through bus
20
to the processing unit. However, for this to occur, the software will have to be given specific information that the DMA device resides on the port to the bus that provides the DMA operations. Typically, this may be accomplished through defining a PCI—PCI bridge such that bus numbers can be defined. However, in order for this to work, software changes may be required because current DMA controller drivers which talk to DMA devices, such as IDE, may not work behind a PCI bridge under certain operating systems (e.g., Windows 98).
Another disadvantage of the architecture according to
FIG. 1
is that sending processing unit configuration cycles across one bus (e.g., bus
20
) may incorporate a high overhead. The data size may be small and may interrupt high-speed data transfers from DMA controller operations, thus lowering overall system performance.
Moreover, the architecture of
FIG. 1
becomes problematic as more DMA controller devices need to be added to I/O controller
18
. In the architecture in
FIG. 1
, data and other information (e.g., configuration data from processing unit
14
) passes through one bus
20
. As more DMA controllers are added to the I/O controller, the bandwidth needed out of the port on I/O controller
18
driving bus
20
needs to be increased. However, bus
20
may only be capable of handling up to a certain amount of bandwidth since bus
20
may be limited by items such as: clock frequency, layout constraints on the motherboard, cost of the motherboard, arbitration issues, etc.
More buses may be added to help address this problem. However, when more ports are added (for additional buses), a new issue arises as to which bus processing unit
14
uses to read the status of each DMA controller device. In the architecture in
FIG. 1
, processing unit
14
always sends instructions and requests through one bus (e.g., bus
20
). However, when multiple ports and buses exist, the processing unit must know which port and bus to use to access a particular DMA controller device. If a DMA controller uses one bus for access memory, and the processing unit uses a different bus for reading status of the memory access from the DMA controller, a coherency issue between the buses arises. That is, for example, the processing unit may be unsure as to whether data has been actually written to memory (and not sitting in FIFO
24
) when the DMA controller send status back to processing unit
14
that the DMA operation (read) has been completed.
REFERENCES:
patent: 5241630 (1993-08-01), Lattin, Jr. et al.
patent: 5249283 (1993-09-01), Boland
patent: 5671371 (1997-09-01), Kondo et al.
patent: 5859988 (1999-01-01), Ajanovic et al.
patent: 5905912 (1999-05-01), Story et al.
patent: 6115551 (2000-09-01), Chao
patent: 6240481 (2001-05-01), Suzuki
patent: 6438634 (2002-08-01), Watanabe et al.
patent: 6460108 (2002-10-01), McCoskey et al.
patent: 6549964 (2003-04-01), Lai et al.
Huter Jeffrey B.
Myers Paul R.
Phan Raymond N
LandOfFree
Method and system for keeping two independent busses... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and system for keeping two independent busses..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and system for keeping two independent busses... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3183325