Electrical computers and digital data processing systems: input/ – Input/output data processing – Input/output data buffering
Reexamination Certificate
1999-10-12
2003-06-03
Gaffin, Jeffrey (Department: 2182)
Electrical computers and digital data processing systems: input/
Input/output data processing
Input/output data buffering
C710S113000, C711S151000, C358S001130
Reexamination Certificate
active
06574688
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to computer and communications systems. In particular, the invention relates to technology for connecting external devices with a computer or communications system.
2. Description of the Related Art
Many computer or communications systems that perform peripheral input/output functions or other network data exchange functions rely on one or more function modules to interconnect the system with one or more external devices. A function module is an input/output block facilitating data communication between a device external to a computer or communications system and internal components located within that system. Examples of function modules include processor cores and interface cores. Examples of internal components include host components such as system memory and central processing units (CPUs). Examples of external devices include hard disk drives, printers, external modems, floppy disk drives, and CD-ROMs. Traditionally, the function modules and host components are located on a single circuit board or on a single integrated chip.
Function modules need to be interconnected to the internal components. This interconnection facilitates data information sharing among the various function modules. For example, a function module may receive data from an external device and transmit the data to the system memory (also known as “writing” to the system memory). Alternatively, the function module may receive data from the system memory (also known as “reading” from the system
FIG. 1
is a block diagram illustrating a prior art system
100
wherein five function modules
101
-
109
are inter-connected via a local bus
120
. In an exemplary case, function module
101
is an IEEE 1394-95 controller, function module
103
is a peripheral component interconnect (PCI) bridge, function module
105
is an ethernet controller (in accordance with IEEE 802.3 Standard), function module
107
is a universal serial bus (USB), and function module
109
is a high-speed integrated device electronics (IDE) controller. In addition, each function module is directly connected to an external device
151
-
159
(external to the integrated circuit where the function modules and the host components are located).
Local bus
120
is connected to a central arbitrator
122
, which in turn is directly connected to a host component
130
(e.g., system memory or CPU). Arbitrator
122
controls the traffic on local bus
120
. The traffic on local bus
120
represents data exchanged between host component
130
and function modules
101
-
109
. Whenever a function module
101
-
109
needs to write to and/or read from host component
130
, the function module needs an access to local bus
120
. In order to gain access to local bus
120
, the function module sends an access request to arbitrator
122
. Depending on the current traffic on local bus
120
, arbitrator
122
either grants or denies the request. If access is granted, the function module performs the data exchange for a pre-determined period of time or for a pre-defined number of bytes. After the data exchange is complete, the access to local bus
120
is relinquished. At this time, another function module (or the same function module) may request access to local bus
120
, and the cycle is repeated all over again.
Each function module is directly connected to local bus
120
but only one function module can transmit or receive data via local bus
120
at a time. Arbitrator
122
can handle only one access request at a time. Arbitrator
122
relies on bus arbitration wherein all function modules are polled for outstanding requests and then an access is granted to only one function module based on a fixed priority basis. If local bus
120
is already in use by a first function module (i.e., conducting a data exchange) when a second function module requests access to the bus, arbitrator
122
places the request from the second function module on hold. Only after the first function module completes its access to local bus
120
(i.e., completes its data exchange) will arbitrator
122
grant the request from the second function module. As such, the second function module has to wait until the first function module has completed its data exchange. This wait period (i.e., latency) adds to the actual time taken to complete a data exchange by the second function module and adversely affects the performance of the computer or communications system.
Prior art system
100
also requires that function modules
101
-
109
have internal buffers (i.e., memory space) for temporarily storing data. If a function module receives data from an external device but cannot have immediate access to local bus
120
, the function module must hold the data in its internal buffer until access to the bus is granted. Larger internal buffers are required to accommodate longer wait times. Internal buffers are expensive and the dollar cost increases with increased number/size of buffers.
Generally, in prior art system
100
, local bus
120
is balanced to operate at maximum operating frequency. When new function modules are added to local bus
120
or any old function modules are removed from local bus
120
, the prior art requires rebalancing to create maximum operating frequency. This rebalancing adds to the dollar cost. Alternatively, if the design or architecture of the local bus is upgraded or enhanced, the design of function modules accessing local bus
120
may need to be enhanced or replaced. This also adds to the dollar cost.
In the prior art system
100
, each function module has a predefined throughput (i.e., maximum bandwidth). Thus, if a particular function module requires additional bandwidth on local bus
120
to complete a data exchange, the function module may not exceed its allocated maximum bandwidth even though additional bandwidth is available (not used by other functions). To complete the data exchange, the function module must request and wait for another access to local bus
120
. This results in an inefficient use of the available bandwidth on local bus
120
and slows down the performance.
SUMMARY OF THE INVENTION
An improved method and apparatus for connecting various function modules located within a computer or communications system are proposed. In accordance with the principles of the present invention, a port manager controller (PMC) having a direct interface to each of the function modules and to a host component such as a system memory or a CPU is provided. The PMC replaces both the local bus and the arbitrator of prior art systems. All the requests by function modules to access the host component are first processed by the PMC. The PMC schedules the incoming requests in accordance with predefined parameters, such as priority, efficiency, and/or timing.
The PMC is capable of handling more than one request at a time. The PMC is also capable of dynamically adapting to load conditions and rearranging the incoming requests to efficiently utilize the available bandwidth. Thus, the PMC reduces latency and improves the performance of the computer or communications system. The PMC also eliminates the need for changes in bus architecture when new function modules are added or old function modules are removed and permits the reuse of old function modules. The PMC also reduces the need for internal buffers and thereby reduces manufacturing costs.
In one embodiment, the present invention is a port manager controller for controlling access to a host component by a plurality of function modules, wherein the PMC comprises (a) a host component port configured to be connected to the host component; and (b) at least two function module ports, each configured to be connected via a point-to-point connection to one of the function modules. The PMC is configured to (
1
) receive a first access request from a first function module at a first function module port of the PMC, and (
2
) schedule a first access session for data exchange between the first function module and the host component via the ho
Dale Michele Z.
Latif Farrukh A.
Agere Systems Inc.
Gruzdkov Yuri
Mendelsohn Steve
LandOfFree
Port manager controller for connecting various function modules does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Port manager controller for connecting various function modules, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Port manager controller for connecting various function modules will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3160850