Electrical computers and digital data processing systems: input/ – Intrasystem connection – Bus interface architecture
Reexamination Certificate
1999-12-22
2002-11-26
Thai, Xuan M. (Department: 2781)
Electrical computers and digital data processing systems: input/
Intrasystem connection
Bus interface architecture
C710S305000
Reexamination Certificate
active
06487627
ABSTRACT:
BACKGROUND
1. Field
The present invention relates to managing digital bus traffic.
2. Background Information
Modem electronic devices often comprise signal paths known as buses for propagating signals between components of the device. A device may comprise multiple buses, known as local buses, each coupled to one or more components. Signals from two or more local buses may merge onto another bus, known as a shared bus. Signals from multiple local buses, or multiple shared buses, may also merge into a component of the device, such as a switch, router, or bridge component. As the signal traffic on the buses increases, congestion may begin to occur on the shared bus or within the component where the signals merge.
Many types of signals may contribute to bus signal traffic (e.g. bus signal bandwidth), including read request signals, write request signals and read return signals. Read request signals are signals generated by components to request the return of data signals from another component (the target). Often this other component is a memory device. Write request signals are signals generated by components to transmit data signals to other components, again typically a memory. Read return signals are the signals generated by components in response to read request signals, to return data to the requesting component. Of course, many other types of signals are possible on buses as well.
A component known as a bus bridge may be responsible for merging signals from two or more local buses onto a shared bus. A component on one of the local buses may submit a read request signal to the bus bridge. As shown in
FIG. 4
, a read request signal
406
may comprise an address (field A
s
). Of course, the read request signal
406
from the component may comprise substantially more information (indicated by field O) as well which is not shown so as not to obscure the present discussion. The address A
s
may identify a starting address within the target component from which to read data. Note that in one embodiment the read request signal may not indicate the number of bytes to read. Instead, the bridge may generate read request packets
402
to read data beginning at the starting address A
s
, until a time when the component indicates it is no longer interested in accepting returned data, or simply stops accepting returned data. In another embodiment, the request signal
406
may include a number of sequential bytes to read from the address A
s
.
In response to receiving the read request signal
406
from the component on the local bus, the bus bridge may generate multiple read request packets
402
to fulfill the request. Similar to the read request signal
406
from the component on the bus, the read request packet
402
may an address A and a request size M. Read request packet may also include an identifier IDT which may facilitate routing of the request packet
402
and ordering of the read return packets
404
which are produced in response. Of course, the read request packet
402
from the component may comprise substantially more information as well which is not shown so as not to obscure the present discussion. The address A may indicate an address in the target component from which to read data. Initially this may be the same starting address A
s
specified in the read request signal, but subsequently may comprise a different address as data is read sequentially from the target component. The size M may indicate a number of sequential bytes to read from the address A.
Data signals may be returned from the target component by way of read return packet
404
. Read return packets
404
may comprise the routing identifier IDT, the number of bytes of data returned (M), and M bytes of DATA. The bridge component may buffer and forward read return packets
404
to the component on the bus which submitted the read request signal
406
, until the component indicates that it will no longer accept returned data, or stops accepting returned data.
The bridge device may transmit several read request packets
402
before receiving the first read return packet
404
. This behavior is known as prefetch and tends to improve the performance of the device by maintaining signal bandwidth on the bus at levels close to the maximum levels which the bus is capable of sustaining (e.g. improving bus bandwidth efficiency).
One disadvantage of prefetch is that a number or read return packets may arrive for the component after it has indicated that it will no longer accept returned data. Due to prefetch, the bus bridge may have transmitted additional read request packets
402
to the target component which result in returned data which the requesting component does not accept. The additional read return packets are known as overfetch. Overfetch is a side effect of prefetch and tends to waste bandwidth on the shared bus.
Efficient operation of the shared bus may be achieved by utilizing prefetch while attempting to minimize overfetch. Traditional approaches have adjusted the number of prefetched packets according to buffer capacity in the bus bridge component. However, this approach may not adequately compensate for the negative impact of overfetch on bus efficiency.
SUMMARY
A method includes transmitting packets on a bus and maintaining a number of the packets in-flight on the bus according to a number of active streams for the bus.
REFERENCES:
patent: 5974456 (1999-10-01), Naghshineh et al.
patent: 6185672 (2001-02-01), Trull
patent: 6237073 (2001-05-01), Dean et al.
patent: 6237088 (2001-05-01), Zaidi
patent: 6247114 (2001-06-01), Trull
patent: 6266744 (2001-07-01), Hughes et al.
patent: 6330630 (2001-12-01), Bell
patent: 6349380 (2002-02-01), Shahidzadeh et al.
patent: 6393536 (2002-05-01), Hughes et al.
patent: 6405305 (2002-06-01), Meier et al.
Morrow Warren R.
Willke Theodore L.
Blakley Sokoloff Taylor & Zafman LLP
Intel Corporation
Thai Xuan M.
LandOfFree
Method and apparatus to manage digital bus traffic 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 to manage digital bus traffic, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus to manage digital bus traffic will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2915427