Method, apparatus and computer program product for write data transfer

A first device is operable to communicate on an bus according to a first protocol. A bridge is also operable to communicate on the bus according to the first protocol. A second device is coupled to the bus via the bridge and operable to communicate according to a second protocol. The bridge has a memory for holding data received from the second device and is operable to translate from the second to the first protocol. The second device sends write data responsive to receiving a ready signal from the bridge, and includes memory for holding the write data that the second device has sent, but for which completion has not been signaled. The second device re-sends the write data from the memory responsive to receiving a non-completion signal via the bridge, and releases the memory for the data responsive to receiving a completion signal via the bridge.

BACKGROUND

1. Field of the Invention

The present invention relates to transferring data between an initiator and target over a bus, and more particularly concerns such transfers via a bridge that translates between a first and second protocol.

2. Related Art

It is often desirable to develop new computer systems that have improvements in some aspects of the systems, but which selectively reuse some components, or at least minimize changes to some of the components. For example, computer systems commonly include master (a.k.a. “initiator”) and target devices that transfer data over a system bus. In a new release of such a system, it may be desirable to adopt a new or modified bus protocol without changing, or at least minimally changing, certain intitiator or target devices. This may include maintaining support of old bus protocols for the initiator and target devices.

A “protocol” is defined as a “set of formal rules describing how to transmit data. Low level protocols define the electrical and physical standards to be observed, bit- and byte-ordering and the transmission and error detection and correction of the bit stream. High level protocols deal with the data formatting, including the syntax of messages, the terminal to computer dialogue, character sets, sequencing of messages etc. Protocols are defined, for example, in Peripheral Component Interconnect (“PCI”) specifications published by the PCI special interest group, available at www.pcisig.com, and in IBM CoreConnect bus architecture specifications, elements of which include the processor local bus (PLB), the on-chip peripheral bus (OPB), a bus bridge, and a device control register (DCR) bus, defined in specifications available at www.ibm.com. The PCI specifications and CoreConnect specifications are hereby incorporated herein by reference. One conventional approach for addressing these objectives is to require new devices to recognize when they're transferring data to or from an old device and perform the transfer using the old protocol, which the old device still uses. This convention has at least two drawbacks. First, the new devices have increased complexity, because they must support both the old and new protocols. Secondly, when an old protocol device participates in a transfer on the bus, the transfer is typically done at the speed of the old bus. However, the new protocol typically supports higher speed transfers, so this fails to take advantage of the increased speed of the new protocol.

A second approach for addressing these objectives is to provide a “bridge” that converts transfer from the old protocol to the new protocol, and vice versa. This is advantageous from the standpoint that it does not require new devices to support the old protocol.

A bridge may be “simple” or “complex,” depending on how it handles write transactions. A complex bridge performs “write posting” in which the bridge signals to a write initiator the progress, or even completion, of a write transfer before the bridge receives an indication of progress or completion from the destination bus. In a more extreme case, the bridge may even signal progress or completion before the bridge has even sent the write data to the destination. Because write posting involves the bridge gathering and holding data for and information about a write transfer, it allows the bridge to transmit the write data on the destination bus at a speed that is more nearly optimal for that bus. However, write posting also has some drawbacks. First, in this context it is important to maintain necessary ordering requirements for system transfers. For example, ordering logic must be built in to prevent execution of certain read transactions after a bridge has accepted but before the bridge has completed certain write transactions. This logic, of course, adds complexity to the system and may also increase latency. For example, a complex bridge may hold up a transaction due to an ambiguity, although the transaction could actually proceed.

A simple bridge does not include buffering and does not post write transactions nor signal progress to an initiating device until progress has been signaled to the bridge from the target device. This eliminates the ordering problems described above, but results in failure, once again, to take full advantage of the increased speed of the new protocol. That is, an initiator device of the old type, using the old protocol, is only capable of sending data at the slower speed of the old protocol. Since the initiator device using a simple bridge does not sent write data until the target is ready to receive it, once the old initiator is granted control of the bus for the write transfer the bus is monopolized by the transfer for the longer interval required for the slower transfer rate.

Based on the above, it should be appreciated that a need exists for and need exists for improvements in data transfer from one protocol to another.

SUMMARY OF THE INVENTION

The forgoing need is addressed in the present invention. According to one form of the invention, an apparatus for communicating among devices on a bus includes a bus and a first device coupled to the bus and operable to communicate on the bus according to a first protocol. The apparatus also includes a bridge coupled to the bus operable to communicate on the bus according to the first protocol and a second device coupled to the bus via the bridge. The second device is operable to communicate according to a second protocol. The bridge has a memory for holding data received from the second device and is operable to translate from the second to the first protocol. The second device includes logic operable for sending write data for a transaction responsive to receiving a certain ready signal from the bridge, and includes memory for holding the write data that the second device has sent for the transaction, but for which completion has not been signaled. The logic of the second device is also operable for re-sending the write data held in the memory responsive to receiving at least one certain non-completion signal, and for releasing the memory for the data responsive to receiving a completion signal.

It should be appreciated that according to the invention the bridge is capable of converting transfers from an old protocol, e.g., that of the above “second device”, to a new protocol, e.g., that of the above “first device,” and the bridge has memory for buffering write data from the old protocol device, but the bridge does not post writes and therefore does not have all the complexity of the ordering logic of a complex bridge. Instead, to support a certain enhancement in the old protocol between the device and the bridge an initiator device using the old protocol is enhanced with logic that is relatively more simple than the ordering logic of a complex bridge and uses existing or enhanced memory for buffering a write data transfer. According to this enhanced protocol, write data is transferred from the initiator device to the bridge buffer simply in response to a ready signal from the bridge, without first receiving an acknowledgment or ready signal from the target device. Moreover, the bridge does not signal completion or progress of the data transfer to the initiator until the target device signals the completion or progress to the bridge, so there is no premature signaling of completion or progress and therefore the need for complex ordering logic does not arise and performance is enhanced. Thus, according to the invention the design of old-protocol initiator devices is somewhat enhanced, but not necessarily so completely altered as to support a new protocol in its entirety. Additional aspects, objects, advantages and other forms of the invention will become apparent upon reading the following detailed description and upon reference to the accompanying drawings.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

The claims at the end of this application set out novel features which applicant believes are characteristic of the invention. The invention, a preferred mode of use, objectives and advantages, will best be understood by reference to the following detailed description of an illustrative embodiment read in conjunction with the accompanying drawings.

Referring toFIG. 1, a block diagram illustrating a computer system110is shown, according to an embodiment of the present invention. The system110includes a processor115, a volatile memory120, e.g., RAM, a keyboard125, a pointing device130, e.g., a mouse, a nonvolatile memory135, e.g., ROM, hard disk, floppy disk, CD-ROM, and DVD, and a display device105having a display screen. Memory120and135are for storing program instructions, which are executable by processor115, to implement various embodiments of a method in accordance with the present invention. Components included in system110are interconnected by bus140. A communications device (not shown) may also be connected to bus140to enable information exchange between system110and other devices.

Also shown are a master device150coupled to the bus140via bridge155, a master and target device170coupled to the bus140via bridge175, a master device160coupled directly to the bridge140and a target device180coupled directly to the bridge140. InFIG. 1the master devices150and160, target device180and master and target device170are explicitly labeled to emphasize their functions as such, but it should be understood that the processor115, memory135, etc. are also master, target or master and target devices. Master device150, being a master but not a target device, is shown with only one set of control lines A_REQUEST, A_REQSIZE, A_WRDATARDY, A_REARB, A_ADDACK, and A_ACKSIZE, along with write data lines A_WRDATA. (It should be understood that there are additional control, address and data lines for each of the devices that are not shown.) In contrast, master and target device170is capable of bi-directional data transfers and therefore is shown with a set of data and control lines “D” in one direction and another set “G” in another direction. Similarly, bridge155is shown with one set of data and control lines “B” between the bridge155and the bus140, whereas bridge175is shown with two sets, “E” and “H.” Likewise, master device160shown with one set of data and control lines “C,” and target device180is shown with one set of data and control lines “F.”

The control lines mentioned above are for the following signals:REQUEST: a signal that a master sense to its bridge to indicate the desire to transfer write data. REQSIZE: a bus of signals a master sends to its bridge to indicate the desired size of the write transfer.WRDATARDY: a signal a bridge sends to its master to tell the master to send write data. This signal is asserted by the bridge in response to the bridge receiving a write request.REARB: a signal a bridge sends to its master to tell the master that there has been a retry request for a write transaction.ADDRACK: a signal a bridge sends to its master to tell the master that a write transaction is complete. This signal is asserted by the bridge in response to receiving the same signal from the target device for the transaction.ACKSIZE: a bus of signals a bridge sends to a master to tell the master how much of a write data transaction has been completed. This signal is asserted in conjunction with ADDRACK.

Devices150and170are legacy devices that communicate using an older protocol than the protocol of devices160and180supported by the bus140. Consequently, devices160and180are operable to communicate on the bus140using a different protocol than that of devices150and170. For this reason the bridges155and175are interposed between devices150and170, respectively, and the bus140. Bridge155is capable of translating the older protocol of communication received from device150to the newer protocol for communicating on the bus140to devices such as device180. Similarly, bridge175is capable of translating the older protocol of communication received from device170to the newer protocol for communicating on the bus140. Since bridge175and its associated legacy device170are bi-directional, bridge175is capable of translating not only from the older protocol to the newer protocol but also from the newer protocol to the older protocol, such as for a data transfer from device160to device170.

Bridge155has memory155.2for buffering a least some of the write data received from master150in a transaction. This is not for the purpose of re-sending in the event of a retry-type event (as would be the case for a complex bridge), but rather merely because the master150uses the older protocol and is therefore not capable of transferring data at as high a transfer rate as that of the newer protocol supported by the bus140and devices such as master device160and target device180. That is, the memory155.2is for the purpose of accumulating at least some of the data from the master150for a write transaction before the bridge155transfers the data over the bus140. Then, when the bridge155has accumulated enough of the data so that the memory155.2will not under flow, the bridge155may initiated transfer on the bus140at the higher data transfer rate supported by the newer protocol.

According to the embodiment of the invention here illustrated, the legacy master device150is enhanced with memory150.2or already contains memory and is enhanced with logic to use the memory for holding write data sent by the master150until such time as the master150receives an indication on one or more of its control lines that the transfer has been successfully completed, as will be described further herein below. Also, the device150may receive an indication that some or all of the write data for a transaction needs to be re-sent, in which case the write data held in the memory150.2is again sent by the master150, as will be described further herein below. Likewise, the master and target device170has memory170.2for holding write data that it sends until such time as device170receives an indication that the transfer has been completed, etc.

Similarly, according to the embodiment of the invention here illustrated the legacy master device150is has logic150.1to support a certain enhancement in the old protocol between the device150and the bridge155. The logic150.1in the master150and logic155.1in the bridge155is relatively more simple and higher performing than the ordering logic of a complex bridge. The same applies to logic170.1of device170and logic175.1of bridge175. As was stated in the Summary herein above, according to this enhanced protocol write data is transferred from an initiator device such as150to the bridge155buffer simply in response to a ready signal from the bridge155, without first receiving an acknowledgment from the target device, such as device180. However, the bridge155does not signal completion or progress of the data transfer to the initiator device150until the target device180signals the completion or progress to the bridge155, so there is no premature signaling of completion or progress and therefore the need for complex ordering logic does not arise.

Referring now toFIG. 2, in which time proceeds from left to right, details are illustrated concerning how the earlier described signals are used to facilitate data transfers, and concerning the timing of the signals. Beginning at the first event210indicated inFIG. 2for a first write transaction, and referring also toFIG. 1, device150initiates a write transaction by asserting the A_REQUEST signal to bridge155along with a value on the A_REQSIZE lines. In the instance illustrated the size of the requested transfer is four data units. (It should be understood that a data unit could be any predetermined number of bits or bytes.) In response, bridge155asserts the A_WRDATARDY signal to the master150. Responsively, the master150asserts the four data units of data to the bridge155on the A_WRDATA bus.

The bridge155buffers at least some of the data before asserting a request on the B_REQUEST line, thereby requesting to write data on bus140to target device180, together with asserting the request size on the B_REQSIZE lines. (It should be understood that the request is directed to the target device180by means of signals on address lines not shown.) These signals are asserted across the bus140and on the F_REQUEST and F_REQSIZE lines, as shown. In response, the target device180asserts the F_WRDATARDY signal, which is asserted across the bus140and on the B_WRDATARDY line or lines, as shown.

In response to receiving the ready signal, B_WRDATARDY, the bridge155writes the four data units of data on the B_WRDATA bus. These data signals are asserted across the bus140and on the F_WRDATA lines, as shown.

Target device180signals completion, responsive to the device180determining that it can accept all the data, by asserting the F_ADDRACK and F_ACKSIZE signals. Since in the illustrated instance all four data units are received, the F_ACKSIZE signal indicates a value of four, as shown, which is the same value as the initial request size. The F_ADDRACK and F_ACKSIZE signals are asserted across the bus140and on the B_ADDRACK and B_ACKSIZE lines.

In response to receiving the indication of completion, bridge155asserts the A_ADDRACK and A_ACKSIZE signals to the initiator, master device150. The master device150compares the value indicated by the A_ACKSIZE signals to the value initially asserted by the master150on A_REQSIZE and determines that in this instance they are the same and therefore memory150.2, which is holding all the write data that the master150originally sent for this transaction, can now be released. That is, the memory150.2may be flushed now or overwritten in the next transaction.

Next, at220, another write transaction is initiated by master device150by asserting the A_REQUEST signal to bridge155along with a value on the A_REQSIZE lines. In this new instance illustrated, the size of the requested transfer is two data units. In response, bridge155asserts the A_WRDATARDY signal to the master150. Responsively, the master150asserts the two data units of data to the bridge155on the A_WRDATA bus.

The bridge155buffers at least some of the data before asserting a request to target device180on bus140to write the data on the B_REQUEST line together with asserting the request size on the B_REQSIZE lines. (The request is again directed to the target device180by means of signals on address lines not shown.) These signals are asserted across the bus140and on the F_REQUEST and F_REQSIZE lines, as shown. In response, in this instance the target device180is busy and therefore asserts the F_REARB signal, which is asserted across the bus140and on the B_REARB line or lines, as shown. This is a type of non-completion signal and indicates that the transaction should be retried at a later time. (It should also be understood that the transaction may have a tag signal asserted on lines not shown, and that the target device180may assert the tag in connection with any response it sends back to the initiator device150, such as the retry signal, F_REARB, or the completion signals, F_ADDRACK AND F_ACKSIZE.)

In response to receiving the retry signal, B_REARB, the bridge155releases memory155.2allocated to the two data units of data that were received for the current transaction and asserts the A_REARB signal to the master150.

In response to receiving the A_REARB signal, master device150re-initiates the second write transaction by re-asserting the A_REQEST signal to bridge155along with the two-bit value on the A_REQSIZE lines. Responsively, the bridge155again asserts the A_WRDATARDY signal to the master150and the master150again writes the two data units of data to the bridge155on the A_WRDATA bus. This time the data is obtained from the memory150.2, where it was stored in connection with the first attempt at this transaction and where it will continue to be held until such time as the initiator device150receives a completion indication for the transaction.

The bridge155again buffers at least some of the data before asserting a request to target device180on bus140to write the data on the B_REQUEST line together with asserting the request size on the B_REQSIZE lines. These signals are again asserted across the bus140and on the F_REQUEST and F_REQSIZE lines, as shown. In response, the target device180asserts the F_WRDATARDY signal, which is asserted across the bus140and on the B_WRDATARDY line or lines, as shown.

In response to receiving the ready signal, B_WRDATARDY, the bridge155writes the two data units of data on the B_WRDATA bus. These data signals are asserted across the bus140and on the F_WRDATA lines, as shown.

Target device180signals completion, in response to determining this time that it can receive all the data, by asserting the F_ADDRACK and F_ACKSIZE signals. Since in the illustrated instance two data units are received, the F_ACKSIZE signal indicates a value of two, as shown, which is the same value as the initial request size, at220. The F_ADDRACK and F_ACKSIZE signals are asserted across the bus140and on the B_ADDRACK and B_ACKSIZE lines.

In response to receiving the indication of completion, bridge155asserts the A_ADDRACK and A_ACKSIZE signals to the initiator, master device150. The master device150compares the value indicated by the A_ACKSIZE signals to the value initially asserted by the master150on A_REQSIZE and determines that in this instance they are the same and therefore memory150.2, which is holding all the write data that the master150originally sent for this transaction, can now be released. That is, the memory150.2may be flushed now or overwritten in the next transaction.

It should be understood that logical steps described above that are accomplished by the master device150are implemented in logic150.1, according to an embodiment of the present invention. Likewise, logical steps described above that are accomplished by the bridge155are implemented in logic155.1, according to an embodiment of the present invention.

It should also be understood that with respect to write transactions initiated by master and target device170, the device170and bi-directional bridge175operate in similar fashion to that described above for master device150and bridge155, and logical steps for these devices170and175are implemented in logic170.1and175.1, respectively, according to an embodiment of the present invention.

In various embodiments system110takes a variety of forms, including a personal computer system, mainframe computer system, workstation, Internet appliance, PDA, an embedded processor with memory, etc. That is, it should be understood that the term “computer system” is intended to encompass any device having a processor that executes instructions from a memory medium. The memory medium preferably stores instructions (also known as a “software program”) for implementing various embodiments of a method in accordance with the present invention. In various embodiments the one or more software programs are implemented in various ways, including procedure-based techniques, component-based techniques, and/or object-oriented techniques, among others. Specific examples include XML, C++ objects, Java and Microsoft Foundation Classes (MFC).

The description of the present embodiments have been presented for purposes of illustration, but are not intended to be exhaustive or to limit the invention to the forms disclosed. Many additional aspects, modifications and variations are also contemplated and are intended to be encompassed within the scope of the following claims. For example, the invention applies also to a “system” which does not necessarily include a processor. That is, a master and target may communicate across a bus without involvement of a processor. Furthermore, transferring data on a bus may include transferring data across a network.

In one variation, another type of non-completion arises in which some, but not all, data for a write transaction is successfully transferred to a target device. This circumstance is signaled by the target device asserting ADDRACK and ACKSIZE signals, wherein the value indicated by the ACKSIZE signals is less than the number of data units, etc. that was sent by the initiator. The initiator detects this non-completion by comparing the value received from the target device to the value that the target sent in the initial REQSIZE signal. The initiator then re-sends the remaining data units, etc. that were not successfully transmitted in the first attempt, but does not necessarily re-send the initial data units, etc. indicated as having been received. Likewise, the bridge for the initiator detects this non-completion from the ADDRACK signal. The bridge does not compare the value received from the target device to the value that the target sent in the initial REQSIZE signal. It simply releases or flushes memory155.2allocated to the transaction.

The invention has been described in the context of a single computer system110(FIG. 1). However, it should be understood that the invention is equally applicable to transfers from one computer system to another, such as across a network. In such an embodiment of the invention, a master device may itself include a computer system, as may a target device. A bridge from the master device to a bus or network may be internal to the computer system of the master device, may be part of the bus or network, or may be external to both the master and the bus or network.

Referring again toFIG. 1, it should be understood that the logic170.1includes functions to permit master and target device170to send write data as a master, as described herein above for device150, and also to permit the device170to receive write data as a target, as described herein above for device180.

Also, the processes of the present invention are capable of being distributed in the form of a computer readable medium of instructions in a variety of forms. The present invention applies equally regardless of the particular type of signal bearing media actually used to carry out the distribution. Examples of computer readable media include RAM, flash memory, recordable-type media such as a floppy disk, a hard disk drive, a ROM, CD-ROM, DVD and transmission-type media such as digital and/or analog communication links, e.g., the Internet. To reiterate, many additional aspects, modifications and variations are also contemplated and are intended to be encompassed within the scope of the following claims. Moreover, it should be understood that in the following claims actions are not necessarily performed in the particular sequence in which they are set out.