Multimedia system employing timers to properly allocate bus access

[0002] When many devices are connected to a data bus, such as in a multi-media application, conflicts will occur where two devices request access to the bus at the same time. To resolve these conflicts, arbiters have been developed to grant bus access to the device having the highest priority. Thus, when two devices are in contention for the bus, the arbiter first gives access to the device with the higher priority of the two and subsequently gives access to the device with the lower priority.

[0003] In a system with such an arbiter, a device with a very high priority will get frequent access to the bus while a device with a low priority will get infrequent access to the bus. This can present a problem when the devices are assigned their priorities during system initialization or boot-up such that the relative priorities of the devices do not change over time. A situation can exist where a low priority device needs access to the bus in order to continue functioning but cannot obtain access because a high priority device which does not necessarily need access happens to be requesting bus access coincidentally. Thus, although the system is granting access on a priority basis, inefficiencies can result where low priority devices experience idle time or malfunction.

[0004] It is thus an object of the present invention to improve the efficiency of systems where multiple devices request access to a data bus by providing an arbiter with a capability for updating the priority of the respective devices during processing. More specifically, the arbiter of the present invention will utilize timers corresponding to each device. The timers will indicate an elapsed time since each device last had access to the bus. The arbiter will then grant access to the bus based on the values of the timers.

[0005] It is a further object of the present invention to provide a method of granting bus access to a plurality of devices via a bus arbiter which determines priority based upon the time since each device last had access to the bus.

[0006] It is a further object of the invention to provide an arbiter which calculates the priority of each device based not only on the time since each device last had access to the bus, but also on the amount of data needed by the device.

[0007] It is a further object of the invention to provide an arbiter which calculates the priority of each device based not only on the time since each device last had access to the bus and on the amount of data needed by the device, but also on the data transfer rate of each device.

[0008] One embodiment of the present invention comprises a bus connected to a plurality of devices through an arbiter. At least one of the devices has a corresponding timer indicating a value representing the elapsed time since the device last accessed the bus. The arbiter thus grants access to the bus based on the value of the timer. This embodiment can be expanded to associate a timer with each device. This embodiment can also be expanded to include a minimum access interval for one or more of the devices. The timer can then either count up to the minimum access interval from zero, or count down to zero from the minimum access interval. The arbiter can then determine the relative priority for each device based on the time since the device last had access to the bus and the minimum access interval for the device.

[0009] These and other objects of the invention will become apparent from a review of the drawings wherein:

[0010] FIG. 1 shows an example of the invention where three devices are connected to a bus via an arbiter; and

[0011] FIG. 2 shows an alternative connection of three devices to a bus and an arbiter according to the invention.

[0012] FIG. 1 shows three devices A, B and C connected to bus 101 through arbiter 103. Devices A, B and C can be any devices which communicate via bus 101. The connection of each of these devices to bus 101 can be associated with a timer. For example, as shown in FIG. 1, arbiter 103 contains timers 105, 107 and 109 associated respectively with devices A, B and C.

[0013] Alternatively, arbiter 103 can be connected in parallel to connections between devices A, B and C to bus 101 as shown in FIG. 2. In this configuration, timers 105, 107 and 109 are each connected to their respective devices A, B and C via a request line REQ and a grant line GNT. Arbiter 103 is also connected to bus 101 via line 201 to inform bus 101 of which device is granted access. The following discussion focuses on describing the embodiment of FIG. 1 in comparison to conventional arbiters. One skilled in the art will understand that similar operations can be performed using the embodiment of FIG. 2.

[0014] The timers will keep track of the elapsed time since each device last had access to bus 101. This enables arbiter 103 to base its priority decisions on these elapsed times.

[0015] For example, suppose devices A, B and C are video processing devices which receive data from bus 101 for video processing and subsequent display. Further, assume that devices A, B and C are different types of video processing devices targeted to different video applications, such that they have different data input requirements.

[0016] For example, assume device A is a video processor related to a teleconferencing application whereas devices B and C are video processors related to full motion video applications. Since teleconferencing does not require the same frame update rate as full motion video, device A has lower data input requirements compared to the other devices. Further, assume device B is a video processor engaged in color video while device C is a video processor engaged in black and white video. Therefore, since color video requires more data than black and white video, device B would require more data via bus 101 than device C.

[0017] If each time a device accesses bus 101 it receives the same amount of data, for example, one packet of data, then the differing data input requirements of the three devices translate into differing bus access requirements. Thus, device B requires the greatest amount of data and therefore requires the most frequent bus access. Similarly, device C requires the second greatest amount of data and therefore requires the second most frequent bus access, while device A requires the least amount of data and therefore the lowest amount of bus access.

[0018] It should also be clear that although each of the devices needs to access bus 101 at a different rate, if any of the devices is not granted access to bus 101 at a sufficiently frequent interval, a device malfunction may result.

[0019] In a conventional arbitration system, the relative priorities of devices A, B and C would be assigned at the time of system boot-up. For the example discussed above, device B would be given the highest priority, device C would be given the second highest priority and device A would be given the lowest priority.

[0020] A drawback of conventional arbitration systems, however, is that these respective priorities would be maintained indefinitely. Thus, any time device B requests access to bus 101, it will be given access regardless of whether it truly needs to access bus 101. As a result, even if device A needs access to bus 101, its access request will be superseded by the priority of either device B or device C if either of these devices is coincidentally requesting bus access, regardless of their actual need for bus access.

[0021] For simplicity, we are assuming that devices A, B and C receive data from bus 101 in like-size packets. Thus, when device A accesses bus 101, it receives the same amount of data that device B receives when device B accesses bus 101, which is identical to the amount of data device C receives when device C accesses bus 101. As will be discussed later, this requirement for receiving identical amounts of data for each bus access is purely by way of example to assist in understanding a first embodiment of the invention. A subsequent embodiment will address the situation where the devices can receive different amounts of data when accessing bus 101.

[0022] For the present example, therefore, presume the given applications (device A: teleconferencing, device B: color video, device C: black and white video) and the fixed packet size translate into separate minimum access intervals for each device. For example, presume that in order to function properly, device A must access bus 101 at least once every 10 microseconds. Similarly, assume device B must access bus 101 every microsecond and device C must access bus 101 every 2 microseconds. Each time device A accesses bus 101, timer 105 is set in order to keep track of the elapsed time since device A last had access.

[0023] This setting of timer 105 can be accomplished in two different ways. In a first way, timer 105 is reset to zero every time device A accesses bus 101. Timer 105 then counts upward to keep track of the amount of time since the last access. Arbiter 103 then compares the content of timer 105 with a previously stored minimum access interval associated with device A. As discussed above, for this example, the minimum access interval for device A is 10 microseconds. Therefore, arbiter 103 compares the content of timer 105 with 10 microseconds, the difference therebetween representing the amount of time left in the minimum access interval. Alternatively, timer 105 can be reset to the minimum access interval associated with device A (10 microseconds) each time device A accesses bus 101. In this example, timer 105 counts down toward zero such that the content of timer 105 represents the amount of time left in device A's minimum access interval. Thus, arbiter 103 determines device A's minimum access interval by merely reading timer 105.

[0024] In a similar fashion, timer 107 can either be reset to zero and count up to 1 microsecond each time device B accesses bus 101 or be reset to 1 microsecond and count down toward zero each time device B accesses bus 101. Similarly, if a count-up scheme is employed, timer 109 is reset to zero each time device C accesses bus 101 and if a count-down scheme is employed, timer 109 is reset to 2 microseconds each time device C accesses bus 101.

[0025] Arbiter 103 then grants devices A, B and C access to bus 101 based upon the values of their corresponding timers 105, 107 and 109. For example, suppose devices A and B are simultaneously requesting access to the bus. Further, suppose the timers are reset to zero each time their respective device accesses the bus. Further, suppose timer 105 contains a value of 2 microseconds and timer 107 contains a value of 0.8 microseconds. These values indicate that it has been 0.8 microseconds since device B last had access to bus 101 and that it has been two microseconds since device A last had access to bus 101. Since device B needs access every microsecond, arbiter 103 determines that device B has a greater need for access to the bus and grants access to device B. This is because device B must obtain access within the next 0.2 microseconds whereas device A does not need access to the bus for another 8 microseconds. Therefore, in this example, device B is granted priority.

[0026] In another example, suppose devices A and C are requesting simultaneous access to the bus. Further, suppose timer 105 indicates that it has been 9 microseconds since device A last had access to the bus while timer 109 indicates that it has been 0.3 microseconds since device C last had access to the bus. In this situation, device A is granted access to the bus since device A must access the bus within the next 1 microsecond whereas device C requires access within the next 1.7 microseconds.

[0027] Taking an extreme example, suppose all three devices are requesting access to the bus and timer 105 indicates that it has been 9.8 microseconds since device A had access to bus 101, timer 107 indicates that it has been 0.5 microseconds since device B had access to bus 101 and timer 109 indicates that it has been 1.7 microseconds since device C had access to bus 101. Here, priority is given to device A, then to device C and finally to device B, since device A must access bus 101 within the next 0.1 microseconds, device C must access bus 101 within the next 0.3 microseconds and device B must access bus 101 within the next 0.5 microseconds. Therefore, the device which would be given the lowest priority by a conventional arbiter would receive the highest priority in this example. The arbiter of the present invention thus ensures that device A does not experience any malfunction merely because devices B and C are coincidentally requesting access.

[0028] In an alternative embodiment, arbiter 103 can base its priority decisions not only on the content of timers 105, 107 and 109 but also on other factors. These can include, for example, the amount of data required by each device and the rates of data transferred to each device. Thus, suppose device B from the above example can be reconfigured such that it requires access less frequently but receives a greater amount of data each time it has access. For example, suppose devices A and C continue to receive one packet of data each time they access bus 101 but device B is configured such that it receives two packets of data each time it accesses bus 101. Therefore, device B's minimum access interval can be raised from 1 microsecond to 2 microseconds. Arbiter 103 then grants priority based on this new minimum access interval.

[0029] Alternatively, the number of packets of data provided to each device can be variable such that arbiter 103 can set the minimum access intervals of each device based upon the amount of data each device received during its most recent bus access. For example, if device B requires one packet of data every microsecond but received four packets of data during its last access, arbiter 103 can set timer 107 such that device B only requires access within the next 4 microseconds. In this case, the minimum access interval for each device is a function of the way in which data intended for each device is supplied to bus 101.

[0030] Alternatively, devices A, B and C can have differing transfer rates which can variably affect their minimum access intervals. For example, consider the first example presented earlier where all three devices function with the same data transfer rate. Now, presume that the data transfer rate of each device is based on a given application employed by each device. For example, suppose device B's 1 microsecond minimum access interval includes a 0.3 microsecond data transfer period associated with a given application whereas device B can sometimes be engaged in an alternative application for which there is only a 0.1 microsecond data transfer period. In the latter case, when device B is configured for the alternative application, the minimum access interval for device B can be increased to 1.2 microseconds to take advantage of its shorter data transfer period. Thus, arbiter 103 can monitor the configurations of devices A, B and C and adjust the minimum access intervals associated therewith based upon data transfer rates related to various applications.

[0031] Thus, in various alternative ways, arbiter 103 can assign priorities to devices A, B and C to minimize the likelihood that any of the devices will not function due to inaccessibility of bus 101 based on contention for bus access with the other devices. The examples discussed above are based, for simplicity, on three devices accessing the bus. Clearly, however, any number of devices can access the bus and be in mutual contention. The various embodiments of the present invention described above can thus be employed to optimize bus usage.

[0032] While several embodiments of the invention have been described, it will be understood that it is capable of further modifications, and this application is intended to cover any variations, uses, or adaptations of the invention, following in general the principles of the invention and including such departures from the present disclosure as to come within knowledge or customary practice in the art to which the invention pertains, and as may be applied to the essential features hereinbefore set forth and falling within the scope of the invention or the limits of the appended claims.