Read latency across a bridge

Details Read latency across a bridge Read latency across a bridge

1999-01-08

2001-07-10

Etienne, Ario (Department: 2155)

Electrical computers and digital data processing systems: input/

Intrasystem connection

Bus access regulation

C710S052000, C710S058000

Reexamination Certificate

active

06260096

ABSTRACT:

BACKGROUND INFORMATION
1. Field of the Invention
The invention is generally related to computer systems and more particularly to read transactions across bridges.
2. Description of the Related Art
The performance of computer systems can be enhanced through the use of multiple buses that allow a larger number of devices to become part of the system. Devices on one bus can communicate with devices on a physically separate bus through a bridge
108
as shown in the computer system
100
of FIG.
1
. Transactions cross the bridge are requested by an initiator
102
that is coupled to an initiating bus
110
and are directed at a target
104
coupled to a target bus
114
. As the requested data is received from the target one portion at a time, it is stored in the buffer
120
before being forwarded to the initiator.
One type of transaction that is particularly common in such computer systems is the delayed read transaction performed in systems that comply with the popular Peripheral Component Interconnect (PCI) Local Bus Specification, Revision 2.1, Oct. 21, 1994, and with the PCI to PCI Bridge Architecture Specification, Revision 1.0, Apr. 5, 1994, both published by the PCI Special Interest Group, Portland, Oreg.
Typically, after an initial PCI delayed read transaction directed at the target
104
is requested on the first bus
110
, the bridge claims the transaction by latching address and command type information associated with this initial request. This information is indicated as transaction information TR in register
122
. The bridge then immediately signals a Retry termination to the initiator
102
. The Retry signals the initiator
102
to return at a later time for the requested data. The transaction is now enqueued and the bridge
108
attempts to master the enqueued transaction on the target bus
114
by requesting read data from the target
104
at the address specified in the TR.
As the requested data
120
a
,
120
b
, . . . is received from the target
104
one portion at a time, it is stored in the buffer
120
until the initiator
102
returns. When the initiator
102
returns by requesting a read transaction that matches the enqueued transaction, and some or all of the requested data is now available in the buffer
120
, the bridge delivers the data
120
a
,
120
b
. . . to the initiator
102
one portion at a time. If, however, none of the requested data is available in the buffer
120
when the initiator
102
returns, the bridge signals another Retry termination. Repeated requests by the initiator continue to invoke Retry terminations by the bridge so long as the buffer
120
does not contain any of the requested data. This may occur, for instance, if the target
104
or the target bus
114
is busy such that the read data cannot be accessed by the second interface
132
of the bridge.
The above-described conventional methodology of signaling a Retry each time the buffer has no data when the initiator returns adversly affects latency which is an important measure of performance in computer systems. Latency here is defined as the delay, from the time of the initial request, in delivering a portion of the requested read data to the initiator. For instance, consider the situation where some of the requested read data arrives into an empty buffer
120
soon after the initiator
102
is signaled a Retry. The bridge must now wait for the initiator
102
to return before the bridge can deliver any of the recently received read data. This delay increases latency. Moreover, this delay may become longer if transactions other than the enqueued delayed read transaction keep the initiating bus
110
busy, thus preventing the initiator from returning to fetch the read data from the buffer. Therefore, what is desirable is a technique for improving latency in such a situation.
SUMMARY
Accordingly, an embodiment of the invention is directed at a method of handling transactions across a bridge by: receiving an initial request for an initial read transaction from an initiator, receiving a subsequent request for a subsequent read transaction from the initiator, and signaling one or more wait states to the initiator in response to the subsequent request provided the initial transaction is being mastered.
These as well as advantages and features of other embodiments of the invention will be more apparent by referring to the drawings, the written description, and the claims below.


REFERENCES:
patent: 5339449 (1994-08-01), Karger et al.
patent: 5732094 (1998-03-01), Petersen et al.
patent: 5941964 (1999-08-01), Young et al.
patent: 5974456 (1999-10-01), Naghshineh et al.

Affiliated with

Also associated with

Rating

Read latency across a bridge does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Read latency across a bridge, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Read latency across a bridge will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2561185