Patent Application
20110113172
1. Field of the Invention
The present invention generally relates to a shared bus system, and more particularly to a bus arbiter in the context of a shared bus system.
2. Description of the Prior Art
A bus arbiter is used in a shared bus system to resolve bus contention, in which more than one master or agent on the bus attempts to use the bus and its associated resource, such as a shared memory, at the same time. To the extent resolution of the bus contention may be resolved, however, such is typically at a cost of degrading system utilization.
For the reason that conventional bus systems tend to under utilize bus resources, a need has arisen to propose a novel scheme to increase the utilization and performance of performance-compromised bus systems.
In view of the foregoing, it is an object of the embodiments of the present invention to provide a utilization-enhanced arbiter and an arbitration method for shortening the bus idle period, thereby increasing bus utilization and system performance.
According to one embodiment, a utilization-enhanced arbiter arbitrates among multiple masters according to at least one active request sent from the masters, thereby deciding which one of the masters has a right to use a shared bus in order to access a resource. The arbiter sends a passive request to one of the masters in an idle period, during which no data transaction occurs on the shared bus, according to respective status of the masters. Accordingly, the master that receives the passive request may access the resource in the idle period, thereby shortening the idle period and increasing bus utilization and system performance.
According to the embodiment, in step 31, the arbiter 10 determines whether at least one (active) request has been sent from one of the masters (e.g., M1, M2, etc.). For example, a master usually sends a write request whenever its associated (write) first-in first-out (FIFO) register becomes full or almost full (e.g., full/almost-full). On the other hand, a master usually sends a read request whenever its associated (read) FIFO register becomes empty or almost empty (e.g., empty/almost-empty). The mentioned FIFO register is usually located on the respective master's side. Generally speaking, a full/almost full (write) FIFO register indicates that the data prepared for writing to the shared memory 14 are ready for transaction, and an empty/almost empty (read) FIFO register indicates that more data are demanded to be read from the shared memory 14. As used herein, the term “almost full” indicates the data occupancy in the FIFO register being higher than an almost-full threshold value but lower than a full occupancy, and the term “almost empty” indicates the data occupancy in the FIFO register being lower than an almost-empty threshold value but higher than an empty occupancy. Although the FIFO register is used here to indicate the data availability in a master, it is appreciated that the data availability, or status in general, of the master may be represented by another scheme equivalent in function.
If it is determined that at least one request is present at the moment, the arbiter 10 grants the bus 12 privilege to a (e.g., one) master that, for example, sends a request earlier or has a higher priority (step 32). A communication link (e.g., of wires) is coupled between each master and the arbiter, with each link comprising, for instance, a request link for carrying one or both of the write and read requests of the corresponding master and a grant link for carrying a grant. In the embodiment, one pair 16 of request and grant wires is devoted to one (e.g., each) master, for carrying one or both of the request signal and the grant signal, respectively. Afterwards, a data transaction (e.g., writing data or reading data to/from the memory 14) proceeds in step 33.
If it is determined in step 31 that no request is present at the moment and the bus 12 is idle (step 34), the arbiter 10 then checks the respective status of the masters (e.g., of each master) in step 35. Specifically, in the embodiment the arbiter 10 determines whether the (e.g., each) master has reached a predetermined (e.g., an arbiter-defined) refined threshold, which is usually distinct from the full/almost-full threshold and the empty/almost-empty threshold as defined by the respective master and/or as discussed in connection with step 31.
Subsequently, in step 36, the arbiter 10 sends a passive request to one of the masters according to the checked status of the masters, followed by proceeding with the data transaction (step 33). In the embodiment the arbiter 10 sends the passive request to the master that has reached the refined threshold. It is noted that the passive request may be sent via a communication link (e.g., wire) that is the same as the grant wire of the request/grant wire pair 16, or via another (e.g., dedicated) wire. For instance, a dedicated wire may be coupled in each pair of wires for carrying the passive request.
According to the embodiment disclosed above, the arbiter 10 may trigger the data transaction in an active manner in a bus idle period, thereby increasing the occurrence probability of data transaction, shortening the bus idle period, and increasing bus utilization and system performance.
Although specific embodiments have been illustrated and described, it will be appreciated by those skilled in the art that various modifications may be made without departing from the scope of the present invention, which is intended to be limited solely by the appended claims.
