METHOD AND DEVICE PERTAINING TO DATA TRANSFER

Abstract: A device and a method for performing data transfer over a bus. In one embodiment the device comprises a request line adapted for initiating a standard data transfer mode. In turn, the request line is used to send a standard data transfer request to an arbiter. The same request line is further adapted for initiating a special data transfer mode. In turn, the same request line is used to send a special data transfer request to the arbiter. The device also includes a grant line adapted for receiving a grant signal from said arbiter. The same grant line is also adapted for receiving a special grant signal from the arbiter. As such, the present invention provides a bus protocol to that provides different levels of bus requestpriority from the device to the arbiter, while not needing any extra pin. The standard data transfer typically indicates asynchronous transfer, whereas the special data transfer typically indicates isochronous data transfer.

Description: METHOD AND DEVICE PERTAINING TO DATA TRANSFER FIELD The present disclosure relates to data transfers over a computer bus. Specifically, the present disclosure relates to a computer bus protocol for data transfers over the computer bus. In one aspect this disclosure discusses using a request line and grant line to implement a serial protocol to indicate more than a standard request to an arbiter. BACKGROUND Bus access requests from a device may have different levels of request priorities. For example, whereas typically the device can indicate to an arbiter one type of data transfer such as an asynchronous data transfer, the device may also need to indicate to the arbiter another type of data transfer request such as an isochronous data transfer. Continuing with the given example, the device typically gains bus access by sending a data transfer request to an arbiter of the bus. If the data transfer is allowed by the arbiter, then the arbiter sends a grant signal to the device to indicate that the bus is now available for data transfer from/to the device. Specifically, for the asynchronous data transfer, no set time interval is guaranteed to the device that has gained bus access. However, for a data transfer such as streaming video or audio data, any indeterminate of the bus access during the streaming process can cause the quality of the image or sound to deteriorate severely. Thus, as compared to an asynchronous data transfer, an isochronous data transfer is required to ensure that the streaming process can be implemented with a higher level of request priority in bus access, wherein a predetermined period of time of bus access can be guaranteed to the device. Given that the device needs to be able to indicate more than one level of request priorities, extra pins may be implemented to accommodate extra levels of request priorities. However, because the pin count of a mother board limits the pin count of a bus, not all buses permit extra pins. SUMMARY: A need exists for a device to be able to indicate more than one level of data transfer request priority. Specifically, for example, a need exists for a device that is capable of indicating highly prioritized isochronous data transfer requests in addition to the typical lowly prioritized asynchronous data transfer requests. A further need exists for a device that is capable of indicating multiple levels of data transfer request priority without affecting the device's ability to send conventional data transfer request. Yet another need exists for a device that is capable of indicating multiple levels of data transfer priority without the aforementioned limitations. Accordingly, the present invention provides a method and a device for performing data transfer over a bus, wherein the device is adapted to indicate multiple levels of data transfer priorities to an arbiter of the bus using a single data request line. Specifically, for example, the present invention provides a device that is able to indicate isochronous data transfer request in addition to the typical asynchronous data transfer request, wherein the isochronous data transfer is prioritized higher than the asynchronous data transfer in accessing the bus. The present invention further provides a device that is able to indicate more than one level of data transfer request priority via a single request line without affecting the device's ability to send conventional data transfer request via the same request line. For example, the present invention allows an isochronous data transfer request via a request line while still allowing for an asynchronous data transfer request via the same request line, wherein the isochronous transfer has higher priority in bus access. In one embodiment, the device may need to request a bus with different levels of priorities based on the nature of the data the device needs to transfer. A single request line is implemented by encoding a signaling scheme on the single request line. Specifically, the device comprises a request line adapted for initiating a standard data transfer mode. The request line is used to send a standard data transfer request to an arbiter. The same request line is further adapted for initiating a special data transfer mode. The same request line is used to send a special data transfer request to the arbiter. Preferably, the standard data transfer indicates asynchronous data transfer, while the special data transfer indicates isochronous data transfer. The device also includes a grant line adapted for receiving a grant signal from said arbiter. The same grant line is also adapted for receiving a special grant signal from the arbiter. Advantageously, the present embodiment can be implemented on an existing conventional bus (such as a PCI bus) without affecting the operations of other devices coupled to the bus. These and other objects and advantages of the present invention will no doubt become obvious to those of ordinary skill in the art after having read the following detailed description of the preferred embodiments which are illustrated in the various drawing figures. BRIEF DESCRIPTION OF THE FIGURES: The accompanying drawings which are incorporated in and form a part of this specification, illustrate embodiments of the invention and together with the description, serve to explain the principles of the invention: Figure 1 depicts a bus system in accordance with one embodiment of the present invention. Figure 2 depicts a timing diagram of data transfer for one embodiment of the present invention. Figure 3 depicts a timing diagram of data transfer for another embodiment of the present invention. Figure 4 is a flow chart outlining steps performed for data transfers in accordance with the present invention. DETAILED DESCRIPTION OF THE FIGURES Reference will now be made in detail to the preferred embodiments of the invention, a method and apparatus for using a request line to implement a serial protocol to indicate more than standard request to an arbiter, examples of which are illustrated in the accompanying figures. While the invention will be described in conjunction with the preferred embodiments, it will be understood that they are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, in the following detailed description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be obvious to one ordinarily skilled in the art that the present invention may be practiced without these specific details. In other instances, well known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the current invention. Referring now Figure 1, a bus system 100 is shown outlining the layout of one embodiment of the present invention. Bus system 100 includes a memory bus 106 and a peripheral bus 112 coupled together by a bridge 108. Bridge 108 includes an arbiter 110 for arbitrating bus 112. Beside coupling to bridge 108, bus 106 is coupled to CPU 102 and memory unit 104. Also, beside coupling to bridge 108, bus 112 is coupled to peripheral devices 114, 116, and IEEE 1394 controller 118. Additionally, each of devices 114, 116, and IEEE 1394 controller 118 has direct point-to-point request line and grant line to arbiter 110. In particular, device 114 is coupled to arbiter 110 via a request line 141 and a grant line 142; device 116 is coupled to arbiter 110 via a request line 161 and a grant line 162; and IEEE 1394 controller 118 is coupled to arbiter via a request line 181 and a grant line 182. Also as shown, a camcorder 120 is coupled to device 118 via line 199, and thus indirectly coupled to bus 112. Continuing with Figure 1, bus 112 in the present embodiment is a Peripheral Component Interconnect (PCI) bus that implements an asynchronous data transfer protocol, wherein bus access to a device is not deterministic. Specifically, arbiter 110 coordinates asynchronous bus accesses of devices 114, 116, and IEEE 1394 controller 118. For example, if data from device 118 is intended to be sent over bus 112 to bridge 108, device 118 sends a data transfer request to arbiter 110 via request line 181. In turn, arbiter 110 sends via grant line 182 a grant signal to device 118 to grant device 118 bus access. Because asynchronous protocol is implemented for bus 112, arbiter 110 can discontinue the grant for device 118 when arbiter 110, for example, receives via request line 141 a data transfer request from device 114. However, device 118 may continue to send data until it has no more data. In the present embodiment, IEEE 1394 controller 118 sometimes requests isochronous data transfer over bus 112 in addition to asynchronous data transfer over bus 112. Camcorder 118 is an IEEE 1394 compliant camcorder. Conventionally, isochronous data transfer is coordinated with an extra wire between an IEEE 1394 controller and an arbiter, wherein this extra line is adapted for notifying the arbiter that an isochronous data transfer is requested by the IEEE 1394 controller. As discussed above, adding an extra wire may violate pin count or assignment requirement of the standard PCI bus. The present embodiment advantageously bypasses the need for adding extra wire between the IEEE 1394 controller and the arbiter. The present embodiment uses just request line 181 by using request line " 181 to " send both asynchronous and isochronous data transfer requests. Still referring to Figure 1, request line 181 is operable in a standard data transfer request mode and one or more special data transfer request modes. Request line 181 is adapted for initiating the standard data transfer mode by sending a standard data transfer request to arbiter 110. Significantly, according to the present embodiment, request line 181 is further adapted for initiating any one of the available special data transfer modes by sending a special data transfer request to arbiter 110. In the present embodiment, one of the special data transfer requests is an isochronous data transfer request. Nevertheless, as understood herein, the special data transfer request need not be limited to isochronous data transfer request. Other special sending option/signals are also allowed. Whereas the conventional approach implements an extra line devoted to send information about the special request in parallel to information sent via the standard request line, device 118 sends information about the special request serially (via request line 181) to arbiter 110. As such, device 118 of the present embodiment provides arbiter 110 information about the special request by using request line 181. Continuing with Figure 1, grant line 182 is adapted for receiving a grant signal from arbiter 110. Grant line 182 is also operable in a standard data transfer mode and one or more special data transfer modes. A standard grant signal from arbiter 110 is received by device 118 via grant line ' 182 to indicate availability of the bus. A special grant signal from arbiter 110 is also received by device 118 via grant line 182 to indicate availability of bus 112 for access. Request line 181 and grant line 182 are coupled to arbiter 110 under a point-to-point configuration. In so doing, request line 181 and grant line 182 are independent of the bus clock for bus 112. In particular, request line 181 and grant line 182 are capable of a clock rate higher than that of bus 112. As such, in accordance with the present invention, various signaling schemes/protocols can be implemented to sent information between arbiter 110 and device 118 such that more information than normally allowed by request line 181 and grant line 182 can be conveyed between arbiter 110 and device 118. Figures 2 and Figure 3 illustrate two examples of signaling protocols for request line 181 and grant line 182. Referring now to Figure 2 in view of Figure 1, a timing diagram is shown in accordance with one signal protocol for bus system 100 of Figure 1. Figure 2 is an exemplary timing diagram showing both an asynchronous and an isochronous data transfer requests using request line 181. The signals shown in Figure 2 in view of Figure 1 are signal PCICLK 210, signal REQ 220, and signal GNT 230. Signal PCICLK 210 is the signal that indicates clock cycles of bus 112 as a PCI bus in the present embodiment. Signal REQ 220 is a possible signal on request line 181. Signal REQ 220 is used for requesting asynchronous bus access of bus 112. Signal REQ 230 is another possible signal on request line 181. Signal REQ 230 " is use for requesting isochronous bus access of bus 112. Signal GNT 240 is a signal on grant line 182. Signal GNT 240 is used for granting bus access of bus 112. In order to send an asynchronous data transfer request from device 118 to arbiter 110, signal REQ 220 is brought low at clock edge A of signal PCICLK (the beginning of a clock cycle) to initiate an asynchronous data transfer request to arbiter 110. A few clock cycles later, at clock edge B (the beginning of a clock cycle), signal GNT 240 is brought low to grant asynchronous bus access to device 118. A cycle later at clock edge C, signal REQ 220 is brought high, ready to initiate another data transfer request to arbiter 110. At clock edge D, signal GNT 240 is brought high, indicating to device 118 that it should release bus 112. In order to send an isochronous data transfer request from device 118 to arbiter 110, signal REQ 230 is toggled (rather than simply brought low) so that arbiter 110 is able to differentiate the isochronous data transfer request from an asynchronous data transfer request. As understood in the present embodiment, the isochronous data transfer request is considered a special data transfer request of bus 112, whereas an asynchronous data transfer request is considered a standard data transfer request of bus 112. Specifically, REQ 230 is toggled by being brought low at clock edge A for an half cycle, brought high at clock edge X, then brought low again at clock edge Y after another half clock cycle. After toggling REQ 230, at clock edge B, GNT 240 is brought low to grant device 118 isochronous access to bus 112. A clock cycle later at clock edge C, REQ 230 is brought high, ready to initiate another data transfer request to arbiter 110. At clock edge D, GNT 240 is brought high, ready to send another grant signal. As understood herein, via request line 181 the standard request (using REQ 220) and the special request (using REQ 230) are performed as specified by a bus request protocol. The bus request protocol provides different levels of request priority from IEEE 1394 controller 118 to arbiter 110 while not needing any extra pin for arbiter 110. However, request line 181 can also have other signaling protocols to convey different information to arbiter 110. That is, a special data transfer request (e.g., signal REQ 230) need not be limited to an isochronous data transfer request. In addition, as understood herein, a standard request signal (e.g., signal REQ 220) need not be limited to an asynchronous data transfer request. Moreover, as understood herein, grant line 182 need not be limited to the signaling protocol shown in Figure 2. In another embodiment, a signal GNT different from GNT 240 is implemented on grant line 182 to send different information to device 118. Referring now to Figure 3 in view of Figure 1, a timing diagram of another embodiment is shown in accordance with another signal protocol for bus system 100 of Figure 1. Specifically, Figure 3 depicts an exemplary timing diagram of two special data transfer requests additional to a standard data transfer request using request line 181. These two special data transfer requests are shown to highlight the fact that more than one special data transfer request can be implemented. That is, more than one special data transfer modes are possible. Moreover, a special data transfer request need not be an isochronous data transfer request. In the present embodiment, bus 112 is a PCI bus having a PCI bus clock with clock cycles as shown. The two special data transfer requests are isochronous data transfer requests with different levels of request priorities. The standard data transfer request is an asynchronous data transfer request. The signals shown in Figure 3 in view of Figure 1 are signal PCICLK 310, signal REQ 320, signal REQ 330, signal REQ 340 and signal GNT 350. Signal PCICLK 310 is the signal that indicates clock cycles of bus 112 as a PCI bus in the present embodiment. Signal REQ 320 is a possible signal on request line 181. Signal REQ 320 is used for requesting asynchronous bus access of bus 112. Signal REQ 330 is another possible signal on request line 181. Signal REQ 330 is used for requesting a first type of isochronous bus access of bus 112. Signal REQ 340 is yet another possible signal on request line 181. Signal REQ 340 is used for requesting a second types of isochronous bus access of bus 112. Signal GNT 330 is a signal on grant line 182. Signal GNT 330 is used for granting bus access of bus 112. For an asynchronous data transfer request from device 118 to arbiter 110, REQ 320 is brought low at clock edge A of PCICLK 310 (the beginning of a clock cycle) to initiate a asynchronous data transfer request to arbiter 110. A few clock cycles later, at clock edge B (the beginning of a clock cycle), GNT 350 is brought low to grant device 118 asynchronous access to bus 112. A cycle later at clock edge C, REQ 320 is brought high, ready to initiate another data transfer request to arbiter 110. At clock edge D, GNT 350 is brought high, ready to grant another data transfer request. In order to send the first type of isochronous data transfer request from device 118 to arbiter 110, REQ 330 is toggled (rather than simply brought low) so that arbiter 110 is able to differentiate the isochronous data transfer request from the asynchronous data transfer request and the second type of isochronous data transfer request. In the present embodiment, the first type of isochronous data transfer request is a special data transfer request of bus 112, whereas the asynchronous data transfer request is considered a standard data transfer request of bus 112. Specifically, REQ 330 is toggled by being brought low at clock edge A for an half cycle, brought high at clock edge X, then brought low again at clock edge Y after another half clock cycle. After the toggling is finished, at clock edge B, GNT 350 is brought low to send a special grant signal of first type to device 118. The special grant signal of first type grants device 118 isochronous access to bus 112. A clock cycle later at clock edge C, REQ 330 is brought high, ready to initiate another data transfer request to arbiter 110. At clock edge D, GNT 350 is brought high, ready to send another grant signal. In order to send the second type of isochronous data transfer request from device 118 to arbiter 110, REQ 340 is also toggled (rather than simply brought low) so that arbiter 110 is able to differentiate the isochronous data transfer request from the asynchronous data transfer request and the first type of isochronous data transfer request. As compared to the toggling for the first type of isochronous data transfer request, REQ 340 according to the second isochronous data transfer request is toggled at a higher frequency with more closely spaced highs and lows. As understood in the present embodiment, the second type of isochronous data transfer request is also considered a special data transfer request of bus 112, whereas the asynchronous data transfer request is considered a standard data transfer request of bus 112. Specifically, REQ 340 is toggled by being brought low at clock edge A for a quarter clock cycle, brought high at clock time XX, brought low again at clock edge X, brought high again at clock time YY, then brought low again at clock edge Y after another quarter clock cycle. After the toggling, at clock edge B, GNT 350 is brought low to send a special grant signal of second type to device 118. The special grant signal of second type grants device 118 a second level of access priority to bus 112. A clock cycle later at clock edge C, REQ 340 is brought high, ready to initiate another data transfer request to arbiter 110. At clock edge D, GNT 350 is brought high, ready to send another grant signal. As understood herein, via request line 181 the standard request (using REQ 320), the first, type of special request (using REQ 330), and the second type of special request (using REQ 340) are performed as specified by a bus request protocol. Using request line 181, the bus request protocol provides different levels of request priority from IEEE 1394 controller 118 to arbiter 110 while not needing any extra pin for arbiter 110. However, request line 181 can also have other signaling protocols to convey different information to arbiter 110. That is, the first and second types of special data transfer requests need not be limited to the two isochronous data transfer requests of the present embodiment. Moreover, as understood herein, grant line 182 need not be limited to the signaling protocol shown in Figure 3. In another embodiment, a GNT different from GNT 350 on grant line 182 is adapted to implement a different protocol to send different information to device 118. Referring now to Figure 4, a flow chart 400 is shown outlining steps performed for indicating a standard data transfer request or a special data transfer request using one request line in accordance with one embodiment of the present invention. These steps are performed for transferring data over a bus by a device coupled to the bus. In the present embodiment, the bus is a peripheral component interface (PCI) bus, and wherein the device is an IEEE 1394 controller. In addition, the standard data transfer mode is adapted for asynchronous data transfer, whereas the special data transfer mode is adapted for isochronous data transfer. However, as understood herein, the bus need not be a PCI bus. In another embodiment of the present invention, a different bus that implements a different protocol is used. In query step 410, the device decides if the data transfer request is a standard data transfer request or a special data transfer request. If the device will send a standard data transfer request to the arbiter, then steps 421, 431, 441 and 451 are performed. Otherwise, if the device will send a special data transfer request to the arbiter, then steps 422, 432, 442 and 452 are performed. In step 421, a standard data transfer mode is initiated by the device. Specifically, the device uses a request line to indicate a standard request to the arbiter. Step 421 is followed by step 431. In step 431, the standard data transfer request is indicated to the arbiter via the request line. Specifically, the standard request is sent from the device to the arbiter using request line to provide arbiter information about the standard request. Step 431 is followed by step 441. In step 441 of Figure 4, the device receives a standard grant signal from the arbiter to indicate availability of the bus by using a grant line. Step 441 is followed by step 451. In step 451, the arbiter grants the device access to the bus by sending via the grant line a standard grant signal from the arbiter to the device. Flow chart 400 terminates. On the other hand, if a special data transfer request is initiated by the device in step 410, then in step 422 a special data transfer mode is initiated by the device. Specifically, the device uses the same request line to indicate a special request to the arbiter. Step 422 is followed by step 432. In step 432, the special data transfer request is indicated via the request line. Specifically, rather than being sent via an extra point-to-point request line connecting the arbiter and the device, the special request is sent from the device to the arbiter using the existing request line to provide the arbiter information about the special request. Step 432 is followed by step 442. In step 442, the device receives a special grant signal from the arbiter to indicate availability of the bus by using the same grant line used for the standard grant signal. Step 442 is followed by step 452. In step 452, the arbiter grants the device access to the bus by sending via the grant line a special grant signal from the arbiter to the device. Flow chart 400 terminates. In conclusion, the present invention enables the request and the grant lines to implement a serial protocol to indicate more than one types of request and grant to/from the arbiter. Thus, the present invention provides a device that is be able to. indicate more than one data transfer request priorities. " Specifically, for example, the present invention provides a device that is able to indicate isochronous data transfer request in addition to the typical asynchronous data transfer request. The present invention further provides a device that is able to indicate more than one data transfer request priorities without affecting the device's ability to send conventional data transfer request. That is, a device is able to implement multiple data transfer request types while using existing bus. For example, the present invention allows one or more types of isochronous data transfer over the bus, while still allowing for a lower prioritized asynchronous data transfer. The foregoing descriptions of specific embodiments of the present invention have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the invention to the precise forms disclosed, and obviously many modifications and variations are possible in light of the above teaching. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, to thereby enable others skilled in the art to best utilize the invention and various embodiments with various modifications as are suited to the particular use contemplated. The scope of the invention is intended to be defined by the Claims appended hereto and their equivalents.

Claims: CLAIMS: What is claimed is: 1. A method of transferring data over a bus by a device coupled to said bus, said method comprising the steps of: (a) initiating a standard data transfer mode from said device to said bus by using a request line to indicate a standard request from said device to an arbiter; and (b) initiating a first special data transfer mode from said device to said bus by using said request line to indicate a special request of first type from said device to said arbiter. 2. The method as recited in Claim 1, wherein said standard data transfer request and said first special data transfer request are specified as a first bus request protocol that provides different levels of request priority from said device to said arbiter while not needing another pin for said arbiter. 3. The method as recited in Claim 1, further comprising the steps of: (c) receiving by said device a standard grant signal from said arbiter to indicate availability of said bus by using a grant line; and (d) receiving by said device a special grant signal from said arbiter to indicate availability of said bus by using said grant line. 4 The method as recited in Claim 3, wherein said step (c) and said step (b) are specified as a bus grant protocol that provides different levels of grant priority from said device to said arbiter while not needing another pin for said arbiter. 5. The method as recited in Claim 1, wherein said bus is a peripheral component interconnect (PCI) bus, and wherein said device is a IEEE 1394 controller. 6. The method as recited in Claim 1, wherein said standard data transfer mode is adapted for asynchronous data transfer. 7. The method as recited in Claim 1, wherein said special data transfer mode is adapted for isochronous data transfer. 8. The method as recited in Claim 1, further comprising the steps of: initiating a second special data transfer mode from said device to said bus by using said request line to indicate a special request of second type from said device to said arbiter; and receiving by said device a special grant signal of second type from said arbiter to indicate availability of said bus by using said grant line, wherein said standard data transfer request, said first and said second special data transfer requests are performed as specified by a second bus request protocol that provides different levels of request priority from said device to said arbiter while not needing any extra pin for said arbiter. 9 A device for performing data transfer over a bus, said device comprising: a request line operable in a standard data transfer mode and a special data transfer mode, wherein said request line is adapted for initiating said standard data transfer mode by sending a standard data transfer request from said device to an arbiter, and wherein said request line is further adapted for initiating a special data transfer mode by sending a special data transfer request from said device to said arbiter, and a grant line adapted for receiving a grant signal from said arbiter 10 The device of Claim 9, wherein said request line is operable in a plurality of special data transfer modes additional to said special data transfer mode, and wherein said grant line is also operable in said plurality of special data transfer modes additional to said special data transfer mode 1 1 A device for performing data transfer over a bus, said device comprising a request line adapted foi initiating a standard data transfer mode by sending a standard data transfer request from said device to an arbiter, wherein said request line is further adapted for initiating a special data transfer mode among a plui ahty of special data transfer modes by sending a special data transfer lequest corresponding to said special data transfer mode from said device to said arbiter, and a grant line adapted for receiving a grant signal by said device from said arbiter. 12. The device of Claim 9 or 1 1 , wherein said request line is for sending data serially from said device to said arbiter to provide said arbiter information that specifies said special request, wherein said standard data transfer request and said special data transfer requests are performed as specified by a bus request protocol that provides different levels of request priority from said device to said arbiter while not needing another pin for said arbiter. 13. The device of Claim 9 or 1 1, wherein said grant line is operable in said standard data transfer mode and said special data transfer mode, wherein a standard grant signal from said arbiter is received by said device via said grant line to indicate availability of said bus; and wherein a special grant signal from said arbiter is received by said device via said grant line to indicate availability of said bus. 14. The device of Claim 9 or 1 1, wherein said bus is a PCI bus, and wherein said device is a IEEE 1394 controller coupled to said PCI bus. 15. The device of Claim 9 or 1 1 , wherein said standard data request transfer mode is asynchronous. 16. The device of Claim 9 or 1 1 , wherein said special data request transfer mode is isochronous. 17. The device of Claim I 1 , wherein said special grant signal corresponds to said special data transfer.

Inventors: FAIRMAN BRUCE A, SMYERS SCOTT D, STONE GLEN D, FAIRMAN, BRUCE, A., SMYERS, SCOTT, D., STONE, GLEN, D.
Applicants: SONY ELECTRONICS INC, SONY ELECTRONICS, INC.
Application year: 2001
Main classification: G06F13
IPC codes: G06F13