Providing device status during bus retry operations

Details Providing device status during bus retry operations Providing device status during bus retry operations

1998-11-30

2001-05-29

Etienne, Ario (Department: 2781)

Electrical computers and digital data processing systems: input/

Intrasystem connection

C710S058000, C710S120000, C710S120000

Reexamination Certificate

active

06240473

ABSTRACT:

BACKGROUND
The invention relates to computer system bus interfaces and, more particularly, to a mechanism for providing device status information during some types of bus read transactions.
Many current computer systems are designed around standard bus architectures such as the Peripheral Component Interface (PCI) standard. (See the “PCI Local Bus Specification, revision 2.1,” available from the PCI Special Interest Group of Hillsboro, Oreg.). Selection of a bus architecture is tantamount to specifying a communication protocol by which disparate devices within the computer system are allowed to communicate.
In a PCI bus computer system, devices may be targets, initiators, or both targets and initiators. Initiators typically initiate bus transactions (e.g., read and write operations), while targets respond to initiator device initiated transactions. (For clarity, bus transactions are referenced from a initiator device's point of view. Thus, a read transaction signifies an initiator device is requesting data from a target device. Conversely, a write transaction signifies an initiator device is attempting to transfer data to a target device.)
Table 1 describes some of the bus transaction control signals used in a 32-bit PCI based computer system. Generally, an initiator initiates a bus transaction by asserting the FRAME# signal and then placing an address on the AD bus. The first rising clock edge after the FRAME# signal is asserted completes the address phase. Following the address phase, the first of one or more data phases begins during which data is transferred between initiator and target on each rising clock edge in which both the IRDY# and TRDY# signals are simultaneously asserted. Wait cycles may be inserted in a data phase by either the initiator device or the target device by deasserting the IRDY# or TRDY# signals respectively.
TABLE 1
Some PCI Bus Transaction Signals
Signal
Description
CLK
Clock provides timing for PCI transactions and is an input to all PCI
devices. All of the following signals are sampled on the rising edge
of CLK. Current PCI buses may operate at a clock of 33 or 66
megahertz (MHz).
AD[31::0]
Address and Data are multiplexed on the same PCI bus lines. A bus
transaction consists of an address phase followed by one or more
data phases. This collection of bus lines constitute the address/data
bus, or AD bus.
FRAME#
Cycle Frame is driven by the current bus initiator to indicate the
beginning and duration of a transaction.
IRDY#
Initiator Ready indicates the current bus initiator is ready and able
to complete a data phase of the current transaction. During a read
transaction, IRDY# indicates the initiator is prepared to accept data.
During a write transaction, IRDY# indicates that valid data is
present on AD[31::0].
TRDY#
Target Ready indicates the target is ready and able to complete a
data phase of the current transaction. During a read transaction,
TRDY# indicates that valid data is present on AD[31::0]. During a
write transaction, TRDY# indicates the target is prepared to accept
data.
STOP#
Stop indicates the current target is requesting the current initiator to
stop the current transaction.
DEVSEL#
Device Select indicates a device has decoded its address as the
target of the current transaction
Note: In accordance with the PCI specification, the symbol ‘#’ denotes a signal that is active (asserted) at a low logic level.
The timing diagram for a basic PCI read transaction is shown in FIG.
1
. As indicated above, read transaction
100
begins with address phase
102
which, in turn, follows assertion of FRAME# signal
104
by the initiator device. During address phase
102
the AD bus (i.e., signals AD[
31
::
0
]
106
) contains the address of the initiator device's intended target device. The initiator device indicates it is able to accept data from the target device by asserting IRDY# signal
108
. Following address phase
102
, the PCI specification requires turnaround cycle
110
during which the AD bus is not driven (this ensures the AD bus is not driven by both an initiator and target device at the same time).
The first rising clock edge following address phase
102
begins data phase
1
112
. In accordance with the PCI specification, the target device drives the AD bus following turnaround cycle
110
when DEVSEL# signal
114
is asserted—in this instance, following the rising edge of clock
3
. The target must continue to drive the AD bus until the transaction completes (i.e., when the initiator deasserts FRAME# signal
104
following clock
7
). Following assertion of DEVSEL#
114
and TRDY#
116
signals, data is transferred on each rising clock edge when both IRDY#
108
and TRDY#
116
signals are asserted, for example, on rising clock edges
4
,
6
, and
8
. On the other hand, if either IRDY#
108
or TRDY#
116
signals are deasserted, a wait cycle is inserted into read transaction
100
and no data is transferred. For example, wait cycles may be inserted during clock cycles
3
,
5
, and
7
.
The initiator knows that the final data will be transferred during data phase
3
118
and so can deassert FRAME# signal
104
following data phase
2
's
120
data transfer. On completion of read transaction
100
, the initiator may place the PCI bus in an idle state by ensuring that both FRAME#
104
and IRDY#
108
signals are deasserted at the same time (not necessarily simultaneously), for example following data phase
3
118
.
In a PCI environment, either an initiator or target device may terminate a bus transaction. Initiator device terminated transactions are referred to as completion and timeout transactions. Target device terminated transactions are referred to as disconnect, target-abort, and retry transactions.
A retry transaction refers to the termination of a read transaction before any data is transferred. Consequently, retry transactions may indicate that a target device is creating a data transfer bottleneck thereby reducing a computer system's effective operating speed. Alternatively, retry transactions may indicate a delayed read or transaction ordering operations. It is generally not possible to accurately determine what is causing a retry transaction. That is, internal target device status information is typically opaque to other bus devices.
Thus, there is a need for a mechanism that a target device causing a retry transaction may use to provide information regarding the target's status without further impeding ongoing data transfer operations. The supplied information may, for example, be used to determine the cause of the retry operations.
SUMMARY
In one embodiment, the invention provides a device to selectively route device information. The device may include a data buffer to receive indications representing a data pattern, a status buffer to receive indications representing a status of a device, a first circuit to indicate when the device is executing a bus retry operation, and a second circuit to selectively route the indications representing device status to an output circuit based on the indication.


REFERENCES:
patent: 5375225 (1994-12-01), Dean et al.
patent: 5717872 (1998-02-01), Whittaker
patent: 5790813 (1998-08-01), Whittaker
patent: 5815647 (1998-09-01), Buckland et al.
patent: 5923856 (1999-07-01), Hazama et al.
patent: 5940234 (1999-08-01), Wilson et al.
patent: 5941964 (1999-08-01), Young et al.
patent: 6040832 (2000-03-01), Poreh et al.

Affiliated with

Also associated with

Rating

Providing device status during bus retry operations does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Providing device status during bus retry operations, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Providing device status during bus retry operations will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-2517613