Shared bus system with transaction and destination ID

Details Shared bus system with transaction and destination ID Shared bus system with transaction and destination ID

1996-10-18

2001-01-09

Sheikh, Ayaz R. (Department: 2781)

Electrical computers and digital data processing systems: input/

Intrasystem connection

Bus access regulation

C710S113000, C710S107000, C710S240000, C710S241000

Reexamination Certificate

active

06173349

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to bus architectures and particularly to low latency shared bus architectures.
2. Description of Related Art
A bus is a communication path between various devices of an electronic system. For example in a computer system, the central processing unit (CPU) communicates with main memory through a memory bus. Peripheral devices may also be connected to the memory bus or connected to the CPU through a separate IO bus.
Buses can be divided into two general categories: point-to-point buses and shared buses. A point-to-point bus connects only two bus devices together. A shared bus can be used by more than two bus devices. Thus the number of buses required for communication depends on whether point-to-point or shared buses are used. For example, four bus devices require six point-to-point buses to communicate with each other, but four bus devices can communicate through a single shared bus. With a shared bus architecture all four bus devices can share a single bus.
Point-to-point buses have the advantage of lower latency, minimal bus contention, and the ability to support multiple simultaneous data transfers. However, the large number of buses used in a point-to-point bus architecture requires a large amount of chip or board area.
Since only a single shared bus can support multiple bus devices, the chip or board area required to implement a shared bus architecture is much less than is required by a point-to-point bus architecture. The primary disadvantage of the shared bus is that arbitration must be performed so that the bus devices can efficiently share the shared bus. Furthermore, device identification is necessary on the bus so that a bus device only receives or responds to signals directed towards that bus device.
With the increasing complexity of electronic systems, data buses have increased in width. The wide data buses preclude the use of many point-to-point buses when chip or board area is costly. Therefore, shared buses are commonly used in complex electronic systems.
FIG. 1
shows a block diagram of a conventional shared bus system
100
. Bus device
120
, bus device
130
, bus device
140
, as well as other possible bus devices (not shown) are coupled together by a shared bus
190
, which contains an address bus
150
, a data bus
160
, and a control bus
170
. On some shared bus systems, the address values and data values are multiplexed on a single combined address/data bus. Each bus device has a bus request output terminal R, a bus grant input terminal G, address terminals ADDR, data terminals DATA, and control terminals CTRL. The bus request output terminals and bus grant input terminals are coupled to a bus arbiter
110
. If bus device
120
wishes to use shared bus
190
, bus device
120
must drive a request active state on bus request output terminal R. The signals, specifically the request, grant, and select signals, in the embodiments and timing diagrams described herein use logic high as the active state and logic low as the inactive state; however, logic low is also commonly used as the active state with logic high being the inactive state. Bus arbiter
110
monitors the bus request signal on a corresponding bus request input terminal. Since arbiter
110
has a bus request input terminal for each bus device, the bus request input terminals are labeled R_x, where x is a number corresponding to each bus device. If shared bus
190
is not in use, bus arbiter
110
drives a grant active state on the grant output terminal coupled to grant input terminal G of bus device
120
to a grant active state. If two devices request the bus simultaneously bus arbiter
110
can use a priority scheme to determine which device receives the bus grant.
The use of separate bus request and grant lines for each device is commonly referred to as independent requesting arbitration. Other commonly used arbitration schemes include daisy chaining and polling.
A bus device which is granted the use of the bus is commonly referred to as a bus master. The bus master communicates with another bus device, which is commonly referred to as the bus slave. A bus device may be capable of being a master only, a slave only, or both a master and a slave. If bus device
120
is granted the bus, bus device
120
becomes the bus master. Bus device
120
then drives address bus
150
and control bus
170
through address terminals ADDR and control terminals CTRL, respectively, to initiate a data transfer. Specifically, bus device
120
would drive address signals onto address bus
150
through address terminals ADDR and control signals onto control bus
170
through control terminals CTRL. Control bus
170
can contain control signals which indicate, for example, the size of the data transfer and the direction of data transfer (i.e. a read or a write).
Typically each bus device is given a range of addresses for the various data under control by that bus device. Therefore, when the bus master drives a device address corresponding to the desired bus slave onto address bus
150
, each bus device must monitor and decode the device address on address bus
150
to determine whether the device address driven by the bus master matches the device address of the bus device. The bus device with a device address which matches the device address driven by the bus master becomes the bus slave. For example, if bus device
120
, currently the bus master, wishes to read data from bus device
140
, bus device
120
must drive the device address for bus device
140
onto address bus
150
. Every other bus device then decode the address to determine whether the device address driven by bus device
120
matches the address of the bus device. In this example, only bus device
140
finds a matching device address. The time for bus device
140
to decode the address adds to the latency of shared bus
190
.
FIG. 2
illustrates the timing of bus arbitration for a typical synchronous shared bus writing data from a bus master to a bus slave. At a first rising edge
201
of clock signal CLK, the requesting bus device drives a request active state on bus request output terminal R, which provides request signal REQUEST to bus arbiter
110
. At a later rising edge
202
, bus arbiter
110
grants the use of shared bus
190
by driving a grant active state onto the grant output terminal coupled to bus grant input terminal G of the requesting bus device, to provide grant signal GRANT. When the requesting bus device receives a grant active state, the requesting bus device becomes the bus master. At rising edge
203
, the bus master drives bus address value
231
on address bus
150
, which corresponds to the desired bus slave, to which the bus master wishes to write data. The non master bus devices decode address value
231
to determine which bus device is the desired bus slave. At rising edge
204
of clock signal CLK, the bus master writes address value
232
on address bus
150
and data value
241
on data bus
160
. Thus, the selection of the bus slave causes a latency of one clock cycle before data is transferred in a synchronous shared bus system.
A read transfer has similar timing to the write transfer shown in FIG.
2
. However, the data would be driven by the bus slave beginning at rising edge
204
of clock signal CLK. If shared bus
190
is used for posted read requests (as explained below), the timing would be identical to
FIG. 2
except that no data is written at rising edge
204
of clock signal CLK. Instead at a later time the bus slave will request the use of the bus to respond to the posted read request. Thus, for a posted read request, the latency of bus slave selection accounts for one-third of the total time required for the posted read request.
Depending on the actual implementation of the shared bus
190
, other control signals may be beneficial. For example, if each bus device uses data FIFOs as a buffer, status flags such as FIFO full and FIFO empty can be used to indicate whether the bus slave is ready to receive or transmit data. In anot

Affiliated with

Also associated with

Rating

Shared bus system with transaction and destination ID does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Shared bus system with transaction and destination ID, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Shared bus system with transaction and destination ID will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2555501