Electrical computers and digital data processing systems: input/ – Intrasystem connection – Bus interface architecture
Reexamination Certificate
2000-08-07
2004-06-22
Auve, Glenn A. (Department: 2112)
Electrical computers and digital data processing systems: input/
Intrasystem connection
Bus interface architecture
C710S314000, C709S241000
Reexamination Certificate
active
06754761
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a communications system, and more particularly to a symmetric bus bridge whose primary and secondary interfaces are separated and in which the role of the primary and secondary interface can be switched under software/application control (thereby providing the symmetry).
2. Description of the Related Art
FIG. 1
illustrates a generic bus architecture for a conventional system. That is,
FIG. 1
shows a system
100
with a typical bus bridge.
System
100
includes a controller
101
(e.g., CPU), a primary bus
102
connecting the controller to one or more devices
103
(e.g., D
1
, D
2
, etc.), a bus bridge
104
connecting the primary bus to a secondary bus
105
and one or more devices
106
(e.g., D
3
, D
4
, D
5
, etc. which may be similar or different from those of devices
103
) connected to the secondary bus
105
.
During system configuration, the bus bridge
104
is responsible for storing and forwarding configuration information from the controller
101
to devices
106
connected to the secondary bus
105
. The bus bridge
104
has an interface B
0
to the primary bus
102
and an interface B
1
to the secondary bus
105
.
The configuration process includes bus numbering, device discovery, and resource allocation (e.g., memory space, IO space, interrupts, etc.) to each of the devices
106
as per device request. After configuration is complete, devices
106
connected to the secondary bus
105
(e.g., behind the bus bridge), appear in the memory map and/or IO map of the controller
101
in the same way as devices
103
connected to the primary bus
102
.
The bridge
104
stores all the pertinent information in its internal configuration register space, which is accessed by the controller
101
during the configuration process. The information stored in the configuration registers is also used regularly at runtime by the bus bridge
104
to decide when to claim transactions originating at one bus and forward it to the other bus. It is noted that only the primary bus interface is allowed to read from/write to the configuration register space of the bus bridge.
In a typical communications environment (e.g., a single bus), a device wishing to communicate by either reading data from or writing data to another device on the bus
102
generally performs the following steps.
That is, for Dx (e.g., one of D
1
, D
2
, etc.) reads from Dy (another of devices D
1
, D
2
, etc.), first Dx arbitrates for bus ownership.
When granted, Dx takes control of the bus and asserts the address of the destination device (Dy) as well as the transaction type it wishes to perform (e.g., read). The transaction may also need to be qualified by other parameters (e.g., memory versus input/output (I/O) read, (starting) address read transaction, single read versus burst mode read, and the number of data elements to read in case of a burst read mode).
All other devices decode the information asserted by the originating device Dx. The addressed device, Dy, responds by acknowledging the transaction.
When Dx sees the acknowledge, it has to relinquish control of the data portion of the bus to enable the target device, Dy, to transmit the requested data. The mechanism of turning the direction of data flow over the bus is implementation specific and may vary from one architecture to another.
Thereafter, Dy transmits the required data element(s) over the bus. Dy could optionally stall the bus until it is ready to transmit the data.
When the required data element(s) is(are) transmitted over the bus, both Dx and Dy relinquish the bus so that it is ready for a new transaction.
For Dx writing to Dy, first Dx arbitrates for bus ownership.
When granted, Dx takes control of the bus and asserts the address of the destination device (Dy) as well as the transaction type it wishes to perform (write). The transaction also may need to be qualified by other parameters (e.g., memory versus I/O write, (starting) address write transaction, (starting) data element, single write versus burst mode write, and the number of data elements to write in case of a burst write mode).
All other devices decode the information asserted by the originating device Dx. The addressed device, Dy, responds by acknowledging the transaction.
When Dx sees the acknowledge, it transmits the desired data element(s) to Dy. Dy could optionally stall the bus until it is ready to receive the data.
When the required data element(s) is (are) transmitted over the bus, Dx releases the bus such that it is ready for a new transaction.
However, as shown in
FIG. 1
, communications can be performed across a so-called “bus bridge”
104
. That is, two busses
102
,
105
can be linked together using the bus bridge
104
. Devices connect to different busses can communicate with each other through the bus bridge. For the purposes of the following discussion, it is assumed that Dx resides at Bus
102
and Dy at Bus
105
.
In contrast to the operations discussed above, for Dx reads from Dy, first Dx arbitrates for Bus
102
ownership.
When granted, Dx takes control of the bus and asserts the address of the destination device (Dy) as well as the transaction type it wishes to perform (e.g., read). The transaction may also need to be qualified by other parameters (e.g. memory versus I/O read, (starting) address. read transaction, single versus burst mode read, and the number of data elements to read in case of a burst read mode).
All other devices decode the information asserted by the originating device Dx. Since Dy resides on Bus
105
, B
0
responds on behalf of Dy by acknowledging the transaction.
When Dx sees the acknowledge, it has to relinquish control of the data portion of the bus to enable the target device, B
0
, to transmit the requested data. The mechanism of turning the direction of data flow over the bus is implementation specific and may vary from one architecture to another.
B
0
stalls Bus
102
until it fetches the requested data from Dy across the bridge.
While stalling Bus
102
, B
0
transmits a request packet across its communications link to the receiving bridge connected to Bus
105
, namely B
1
.
Upon receiving the request, B
1
will read the requested data from Dy. This is achieved by following the steps of “Dx reads from Dy” scenario described above in the above-described first case, but replacing Dx by B
1
.
When the read transaction on Bus B is completed, B
1
will packetize the data and transmit back across the communications link to B
0
.
Then, B
0
starts transmitting the data to Dx. When the required data element(s) is(are) transmitted over the bus, both Dx and B
0
relinquish Bus
102
so that it is ready for a new transaction.
Regarding Dx writes to Dy, first Dx arbitrates for Bus
102
ownership.
When granted, Dx takes control of the bus and asserts the address of the destination device (Dy) as well as the transaction type it wishes to perform (e.g., write). The transaction may also need to be qualified by other parameters (e.g., memory versus IO write, (starting) address write transaction, (starting) data element, single versus burst mode write, and the number of data elements to write in case of a burst write mode).
All other devices on Bus
102
decode the information asserted by the originating device Dx. Since Dy resides on Bus B, B
0
responds on behalf of Dy by acknowledging the transaction.
When Dx sees the acknowledge, it transmits the desired data element(s) to B
0
. B
0
accepts the data, then stalls the bus until it has completed the transaction on the remote side (i.e., Bus
105
). Alternatively, B
0
might release the bus, but not respond to any more transactions until it has completed the current transaction on the remote side.
B
0
transmits a data packet across its communications link to the receiving bridge connected to Bus
105
, namely B
1
.
Upon receiving the data packet, B
1
will write the data to Dy. This is achieved by following the steps of “Dx writes to Dy” scenario described above in the above-described first case, but repl
Asaad Sameh W.
Warren Kevin W.
Auve Glenn A.
Lee Christopher E.
Ludwin, Esq. Richard M.
McGinn & Gibb PLLC
LandOfFree
Communications system including symmetric bus bridge and... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Communications system including symmetric bus bridge and..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Communications system including symmetric bus bridge and... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3304790