EP1264240A2 - Method and device pertaining to data transfer - Google Patents

Method and device pertaining to data transfer

Info

Publication number
EP1264240A2
EP1264240A2 EP01920223A EP01920223A EP1264240A2 EP 1264240 A2 EP1264240 A2 EP 1264240A2 EP 01920223 A EP01920223 A EP 01920223A EP 01920223 A EP01920223 A EP 01920223A EP 1264240 A2 EP1264240 A2 EP 1264240A2
Authority
EP
European Patent Office
Prior art keywords
data transfer
request
arbiter
bus
special
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP01920223A
Other languages
German (de)
French (fr)
Inventor
Glen D. Stone
Scott D. Smyers
Bruce A. Fairman
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Electronics Inc
Original Assignee
Sony Electronics Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Electronics Inc filed Critical Sony Electronics Inc
Publication of EP1264240A2 publication Critical patent/EP1264240A2/en
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/14—Handling requests for interconnection or transfer
    • G06F13/36—Handling requests for interconnection or transfer for access to common bus or bus system
    • G06F13/362—Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control
    • G06F13/364—Handling requests for interconnection or transfer for access to common bus or bus system with centralised access control using independent requests or grants, e.g. using separated request and grant lines

Definitions

  • 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
  • this disclosure discusses using a request line and grant
  • Bus access requests from a device may have different levels of request priorities.
  • the device can indicate to an arbiter one type of data
  • the device may also need to indicate to the
  • arbiter another type of data transfer request such as an isochronous data transfer.
  • the device typically gains bus access by
  • the arbiter sends a grant signal to the device to indicate that the
  • bus is now available for data transfer from/to the device.
  • any indeterminate of the bus access during the streaming process can be any indeterminate of the bus access during the streaming process.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • PCI Peripheral Component Interconnect
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • device 118 sends information about the special request serially (via request line 181) to arbiter 110.
  • device 118 of the present embodiment provides arbiter 110 information about the special request by using request line 181.
  • 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.
  • FIG. 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.
  • 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.
  • clock edge B the beginning of a clock cycle
  • signal GNT 240 is brought low to grant asynchronous bus access to device 118.
  • signal REQ 220 is brought high, ready to initiate another data transfer request to arbiter 110.
  • clock edge D signal GNT 240 is brought high, indicating to device 118 that it should release bus 112.
  • 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.
  • the isochronous data transfer request is considered a special data transfer request of bus 112
  • an asynchronous data transfer request is considered a standard data transfer request of bus 112.
  • 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.
  • 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.
  • GNT 240 is brought high, ready to send another grant signal.
  • 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.
  • 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.
  • a standard request signal (e.g., signal REQ 220) need not be limited to an asynchronous data transfer request.
  • grant line 182 need not be limited to the signaling protocol shown in Figure 2.
  • a signal GNT different from GNT 240 is implemented on grant line 182 to send different information to device 118.
  • FIG. 3 a timing diagram of another embodiment is shown in accordance with another signal protocol for bus system 100 of Figure 1.
  • 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.
  • a special data transfer request need not be an isochronous data transfer request.
  • 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.
  • REQ 320 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.
  • 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.
  • 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.
  • 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.
  • GNT 350 is brought high, ready to send another grant signal.
  • 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.
  • REQ 340 according to the second isochronous data transfer request is toggled at a higher frequency with more closely spaced highs and lows.
  • 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.
  • 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.
  • 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.
  • GNT 350 is brought high, ready to send another grant signal.
  • request line 181 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.
  • 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.
  • 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.
  • grant line 182 need not be limited to the signaling protocol shown in Figure 3.
  • a GNT different from GNT 350 on grant line 182 is adapted to implement a different protocol to send different information to device 118.
  • 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.
  • the bus is a peripheral component interface (PCI) bus, and wherein the device is an IEEE 1394 controller.
  • the standard data transfer mode is adapted for asynchronous data transfer
  • the special data transfer mode is adapted for isochronous data transfer.
  • the bus need not be a PCI bus.
  • a different bus that implements a different protocol is used.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.

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.
EP01920223A 2000-03-17 2001-03-07 Method and device pertaining to data transfer Withdrawn EP1264240A2 (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US52790800A 2000-03-17 2000-03-17
US527908 2000-03-17
PCT/US2001/007199 WO2001071510A2 (en) 2000-03-17 2001-03-07 Method and device pertaining to data transfer

Publications (1)

Publication Number Publication Date
EP1264240A2 true EP1264240A2 (en) 2002-12-11

Family

ID=24103435

Family Applications (1)

Application Number Title Priority Date Filing Date
EP01920223A Withdrawn EP1264240A2 (en) 2000-03-17 2001-03-07 Method and device pertaining to data transfer

Country Status (4)

Country Link
EP (1) EP1264240A2 (en)
JP (1) JP2003528393A (en)
AU (1) AU2001247299A1 (en)
WO (1) WO2001071510A2 (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101223986B1 (en) * 2006-02-23 2013-01-18 삼성전자주식회사 Smart card and smart card system supporting plurality of interfaces

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5758105A (en) * 1995-12-04 1998-05-26 International Business Machines Corporation Method and apparatus for bus arbitration between isochronous and non-isochronous devices
US6012116A (en) * 1997-12-31 2000-01-04 Sun Microsystems, Inc. Apparatus and method for controlling data, address, and enable buses within a microprocessor

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0171510A3 *

Also Published As

Publication number Publication date
JP2003528393A (en) 2003-09-24
AU2001247299A1 (en) 2001-10-03
WO2001071510A3 (en) 2002-01-31
WO2001071510A2 (en) 2001-09-27

Similar Documents

Publication Publication Date Title
US7096292B2 (en) On-chip inter-subsystem communication
JP3231596B2 (en) Bus system with latency and shadow timer
KR20050082834A (en) Bus system for connect sub-system included plural masters to bus based on open core protocol
US5469435A (en) Bus deadlock avoidance during master split-transactions
US6598104B1 (en) Smart retry system that reduces wasted bus transactions associated with master retries
US6959354B2 (en) Effective bus utilization using multiple bus interface circuits and arbitration logic circuit
JP2001318880A (en) Scheduling method for transaction
KR100480605B1 (en) Method of controlling transmitting buffer and receiving buffer of network controller, and the network controller
EP1226504B1 (en) Method and apparatus for supporting multi-clock propagation in a computer system having a point to point half duplex interconnect
US6323755B1 (en) Dynamic bus locking in a cross bar switch
US6532507B1 (en) Digital signal processor and method for prioritized access by multiple core processors to shared device
JP2007122410A (en) Bus arbitration circuit and method
KR101022472B1 (en) Method for using bus efficiently
JP3602435B2 (en) Data transaction method between control chipsets
EP1264240A2 (en) Method and device pertaining to data transfer
JP3377797B2 (en) A method in which a first agent informs a second agent of a need for service on a bus for transferring data between a plurality of data processing agents
US6678780B1 (en) Method and apparatus for supporting multiple bus masters with the accelerated graphics protocol (AGP) bus
US7043595B2 (en) Data transfer control device
US7433989B2 (en) Arbitration method of a bus bridge
US6934789B2 (en) Interface, structure and method for transmitting data of PCI bus which uses bus request signal for judging whether a device supporting dual transmission mode
JP2004194014A (en) Bus controller and information processing system
US7117281B1 (en) Circuit, system, and method for data transfer control for enhancing data bus utilization
JPH09259071A (en) Communication controller
JPH05314067A (en) Data transfer method
JPH09179609A (en) Controller

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20020916

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

AX Request for extension of the european patent

Free format text: AL;LT;LV;MK;RO;SI

17Q First examination report despatched

Effective date: 20030131

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20030611