Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; 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.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Bus Control (AREA)
• Small-Scale Networks (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=24103435

Family Applications (1)

Country Status (4)

Families Citing this family (1)

Family Cites Families (2)

• 2001
  • 2001-03-07 EP EP01920223A patent/EP1264240A2/de not_active Withdrawn
  • 2001-03-07 AU AU2001247299A patent/AU2001247299A1/en not_active Abandoned
  • 2001-03-07 WO PCT/US2001/007199 patent/WO2001071510A2/en not_active Ceased
  • 2001-03-07 JP JP2001569633A patent/JP2003528393A/ja not_active Withdrawn

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events