Electrical computers and digital data processing systems: input/ – Intrasystem connection – Bus access regulation
Utility Patent
1998-01-23
2001-01-02
Auve, Glenn A. (Department: 2781)
Electrical computers and digital data processing systems: input/
Intrasystem connection
Bus access regulation
C710S039000, C710S054000, C710S055000, C709S231000, C711S003000, C711S137000, C711S139000, C711S202000
Utility Patent
active
06170030
ABSTRACT:
FIELD OF THE INVENTION
The present invention relates to the field of managing data flow in a computer system, and more particularly to transferring data between devices on different sides of a bus bridge.
BACKGROUND OF THE INVENTION
To support the high-bandwidth data transfers demanded by modern computer applications, data is clocked across the buses of today's computer systems at tremendous rates. To achieve reliable, high-speed data transfer, a computer system often includes a number of buses arranged in a hierarchy and interconnected by devices called bus bridges.
In essence, a bus bridge is a load isolating device that allows multiple devices to appear as a single capacitive load to the bus to which they are bridged. Although the reduced capacitive loading increases the maximum frequency at which a bus can be operated, the bridge adds a layer of complexity in the design and operation of the computer system. Further complexity may result if the bridge is used to interconnect different types of buses.
One reason that bus bridges add complexity is that requests to transfer data from a requester side of a bridge to a target side of the bridge must often be buffered in the bridge. One reason for this is that the bridge must usually arbitrate with other devices gain control of the target-side bus. Because this arbitration time may vary, it is usually desirable to buffer the requested data transfer and then cause the device which requested the data transfer to relinquish the requester-side bus. Using this approach, other transfers may take place on the requester-side bus while the bus bridge is performing the requested data transfer. If a read operation has been requested, the returned data also must typically be buffered while the bridge notifies the requester that the data is available (or while the bridge waits for the requester to ask if the data is available) and while the requester arbitrates to re-gain control of the requester-side bus.
It will be appreciated that the above-described buffering of requests and data imposes a latency penalty on any data transfer which must cross the bus bridge. Moreover, because the latency penalty is incurred with each transfer across the bridge, the smaller the quantum of data per bridged transfer, the lower the effective bandwidth of the data transfer.
One technique used to avoid loss of bandwidth due to bus bridging is to prefetch additional data in response to each data transfer request. Assuming that the prefetched data is actually used by the requesting device, prefetching effectively increases the quantum of data per bridged transfer and therefore increases the effective bandwidth of data transfer across the bridge.
One problem that may arise when data is prefetched, however, is that, even though the requesting device may need the prefetched data, its internal data buffer may be too shallow to read all of the prefetched data in the bridge in a single read transaction. Consequently, after retrieving a portion of the prefetched data, the requesting device relinquishes control of the requester-side bus (i.e., the requesting device “disconnects”) while it performs the internal operation of transferring the data from its internal data buffer to its other internal resources. Because the requesting device has relinquished control of the bus, the bridge assumes that the requesting device has completed its transfer and reallocates the prefetch buffer for other data transfer operations (remember, the bridge caused data to be prefetched without knowing for certain how much of the prefetched data would be used). The prefetched data remaining in the prefetch buffer is lost when the buffer is reallocated. Consequently, if the requesting device re-gains control of the requester-side bus and attempts to read data beginning where it left off, the read transaction must now cross the bridge and be handled by target-side devices instead of simply accessing data in a prefetch buffer. Thus, in cases where the data buffer of the requesting device is substantially shallower than the prefetch buffer in the bridge, the bandwidth gains achieved by data prefetching can be significantly eroded.
Loss of prefetched data is usually not a problem in a bus bridge that is specifically designed to support split transactions. In a split transaction bus, each transfer request is typically accompanied by an identifier that identifies the requesting device. The identifier allows prefetched data to be matched with a requesting device even if the requesting device disconnects and then reconnects. For example, if a portion of the prefetched data is transferred to a requesting device which then disconnects, the bus bridge can use the identifier which accompanies a subsequent read request to determine whether the subsequent read request is from the same requesting device. If so, the bridge may resume transfer of the prefetched data at the point where the requester stopped the initial transfer. This is referred to as “restreaming” the prefetched data. If the request for the remaining prefetched data is not from the same requester or does not hit the prefetch buffer (i.e., does not request to read data from a prefetched address), a new prefetch operation may be required.
Although the split transaction bus facilitates restreaming of prefetched data after requester disconnect, requiring a the device identifier to accompany each bus transaction adds significant complexity in the design and operation of the computer system. For example, additional signal paths are typically required to carry the device identifier and additional control logic is usually needed to associate device identifiers with respective transactions. Because of this added complexity in design and operation, many types of buses do not require or support requester identification and loss of prefetched data upon requester-disconnect remains a problem.
One solution to the problem of a disconnecting requester is to provide a cache memory in the bridge. By maintaining coherency between data in the in-bridge cache and data in system memory (which is typically on the non-requester side of the bridge), memory read requests that hit the in-bridge cache can be filled without crossing the bridge. Using this technique, no matter how many times a requester disconnects and reconnects (i.e., relinquishes and then reacquires the bus), further access to the non-requester-side bus is not required until a cache miss occurs. Of course, if cache coherency is lost due to modification of the data in system memory, the corresponding cache line in the bridge is invalidated and a further request to read data from that cache line requires the bridge to be crossed in a new prefetch operation.
Unfortunately, in-bridge caching schemes typically require significant additional resources. For example, the bridge must include a cache memory, which typically includes at least a data array, tag array, hit/miss logic and cache line invalidation logic. Also, snooping logic is usually required to maintain coherency between system memory and the bridge's cache. The need for these extra resources significantly increases the complexity and cost of the bridging device. Further, the snooping logic typically presents an additional load on the snooped bus (often the speed-critical, host-side bus), potentially limiting the maximum transfer-rate on that bus.
SUMMARY OF THE INVENTION
An apparatus and method for restreaming data that has been queued in a bus bridging device are disclosed. Data received via a first bus is stored in a queue. A first portion of the data in the queue is output to a second bus while a second portion of the data remains in the queue. The second portion of the data in the queue is invalidated in response to another data value being transferred from the first bus to the second bus before the second portion of the data is output to the second bus.
Other features and advantages of the invention will be apparent from the accompanying drawings and from the detailed description that follows below.
REFERENCES:
patent: 5398325 (1995
Auve Glenn A.
Blakely , Sokoloff, Taylor & Zafman LLP
Intel Corporation
Jean Frantz Blanchard
LandOfFree
Method and apparatus for restreaming data that has been... 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 apparatus for restreaming data that has been..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for restreaming data that has been... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2477112