DE102008034500A1 - arbitration - Google Patents

Abstract

A hierarchical arbitration system includes a plurality of arbitrators, wherein the plurality of arbitrators may be pipelined and at least a portion of the plurality of arbitrators are configured to be selectively operated in a non-pipelined operation.

Description

In Many technical areas become resources through more than one Unit or device shared. For example, in a master-slave configuration a plurality of masters share a common slave, a plurality of units may share a common bus, a plurality of Processors can share a shared memory or parts of it Information, such as data packets, can be transmitted over a common data channel become. If more than one unit has access to a shared resource at the same time, there is a conflict between the units, which in terms of access, before, because of a given When only one of the units can gain access, while for the other access must be prevented.

Around To address this problem, arbitration is used. arbitration is a process in which a unit is given a priority over a given to another unit (or a plurality of other units) becomes. Many arbitration techniques with different degrees of fairness for the requester and different degrees of complexity are known. For example, arbitration can be the number of previous requests a particular unit or the identity of the unit (that is the identity of the terminal) consider. Furthermore, can consider fair arbitration techniques that make inquirers fair For example, a requestor can not be handled by a requestor other requestor is blocked. Include fair arbitration techniques for example, round robin arbitration (RR arbitration), a weighted-round robin arbitration (WRR arbitration) or a deficit-round-robin arbitration (DRR arbitration).

The Object of the present invention is to provide a concept for an improved To create arbitration.

These The object is achieved by a method according to claim 1, an arbitration node according to claim 12, an arbiter system according to claim 16 and an arbitrator system according to claim 20 solved.

The The present invention provides a method in which a plurality operated by arbitrators in a pipeline mode and at least a portion of the plurality of arbitrators in a non-pipelined operation can be done.

at a Ausführungsbeispile Pipeline mode includes providing a first signal from one first arbitrator to a second arbitrator based on a Arbitration in the first arbiter and non-pipelined operation providing a second signal to the second arbitrator independent of an arbitration in the first arbitrator. An arbitration at the second arbiter is based on the second signal.

at an embodiment is the second signal in the pipeline mode and the non-pipeline operation supplied, wherein in the pipeline mode, an arbitration in the second arbitrator based on the first signal via a Arbitration is prioritized based on the second signal.

The A plurality of arbitrators may include a plurality of arbitrators of one hierarchical arbitration system, the first signal a pipeline request signal is and the second signal is a look-ahead signal is. Operating in the pipeline mode may be providing the pipeline request signal from the first arbitrator to a first input port of the second one Arbiter based on the arbitration between the plurality of input ports on the first arbiter, and the second Arbitrator may be parent on a first arbitration Be implemented level. The non-pipeline operation may be a delivery the look-ahead signal to a first input port of the second Arbitrator on a parent Level, wherein the look-ahead signal regardless of is an arbitration in the first arbitrator. Furthermore, a third signal supplied based on the look-ahead signal, the a grant for the first input port displays.

Of the at least a portion of the plurality of arbitrators may be in a non-pipelined operation operated when the at least a part of the plurality of Arbiter in the previous cycle in an idle state or no active pipeline request in the previous cycle having.

Of the Non-pipeline operation can in this case be carried out in parallel Arbitration of a request from at least one requester of a plurality of requestors.

In one embodiment, information is stored for each of the plurality of arbitrators indicating the gates granted grant by a respective one of the plurality of arbitrators. Another embodiment includes providing a data path from a requester to a shared resource based on the information stored for a respective arbiter of the plurality of arbitrators. Further, in one embodiment, in pipelined mode, one request advances one level per clock cycle, while in non-pipelined mode a request is capable of at least two levels of Advance pipeline per clock cycle. In one embodiment, in non-pipelined operation, the request may advance all levels of the pipeline within one clock cycle. In one embodiment, a grantor is granted grant by the plurality of arbitrators for data transfer to a shared resource within one clock cycle after the requestor has issued a request to grant to the plurality of arbitrators when the plurality of arbitrators are in an idle state.

The The invention further provides an arbitration node in a hierarchical Arbitration system, wherein the arbitration node is a first node having a plurality of first inputs to first signals from a child arbitration node. The knot further comprises a first output for sending a signal to an arbitration node a higher one Plane to transfer. The arbitration node further comprises a second node, wherein the second node has a plurality of second inputs to receive second signals receive from second node of subordinate arbitration nodes. Of the second node further has a second output to receive a signal to a parent Arbitrierungsknoten to transfer. The second node may in this case have a combinatorial logic, wherein the combinatorial logic may be implemented to be a plurality of input signals received at the second inputs, and at the output an output signal corresponding to an OR combination to deliver the input signals.

at an embodiment For example, the arbitrator may be coupled to a register that is the arbitration node is assigned to store information that relates to the granted by the arbitrators Receive input.

Further the invention provides an arbiter system comprising a first arbitrator, a second arbiter and a third arbiter. The arbitrator system has a first connection to a first one Signal from a first requester to a plurality of requestors to transmit to the second arbitrator, and a second connection to receive a second signal from one second requester of the plurality of requesters to the first arbitrator transferred to. A third connection is provided based on a third signal on the first and second signals to the third arbiter. Further, a fourth connection is provided to a fourth signal from the first arbiter to the third arbiter. A fifth Connection is provided in the arbiter system to a fifth signal from the second arbiter to the third arbiter. The arbitrator system may be a hierarchical arbitrator system be, arbitration nodes, wherein the first and second arbitrators are assigned to a hierarchical level, while the third arbiter assigned to one of the first hierarchical level parent level is.

The third connection may have a combinational logic, wherein the combinatorial logic has a first and second input and a Having output for outputting the third signal, and wherein the fourth and fifth Connection each have a register to the fourth and fifth signal store, with the register having a control input of a multiplexer is coupled.

Further For example, a data path may be provided that includes the first requester and couples the second requester to a shared resource, where the data path is coupled to the multiplexer to selectively store data based on the signals stored in the register.

The The present invention further provides an arbitrator system having a A plurality of arbitrators, wherein the plurality of arbitrators are formed is to be operated in a pipeline operation, and wherein at least a part of the plurality of arbitrators is formed, to be operated selectively in a non-pipelined operation.

Of the at least a portion of the plurality of arbitrators are in a non-pipelined operation operable when the at least a portion of the plurality of arbitrators is in an idle state.

at an embodiment For example, the plurality of arbitrators may be configured to, when the plurality of arbitrators originally in an idle state is a data transfer for one Inquirer one clock cycle after the requester with respect to one Access has made a request to trigger. The majority of arbitrators may further form a hierarchical arbitration system.

In one embodiment, each of the plurality of arbiters may be coupled to a corresponding register for storing information indicative of goals granted by the plurality of arbitrators. The corresponding register may be coupled to a corresponding multiplexer for providing a data path from a requester to a shared resource based on information stored in each of the respective registers. Further, the plurality of arbiters may be configured to, in the pipeline operation, assert a first signal from a first arbitrator to a second arbiter at a next higher level based on arbitration at the first arbi in the non-pipelined operation, a second signal is provided to the second arbiter independently of the arbitration in the first arbiter. The second signal may be further provided in pipelined operation, wherein arbitration based on the first signal is prioritized via arbitration based on the second signal.

preferred embodiments will be described below with reference to the accompanying drawings explained in more detail. It demonstrate:

1 a block diagram according to an embodiment of the present invention,

2 a block diagram according to an embodiment of the present invention,

3 a block diagram according to an embodiment of the present invention,

4a and 4b Block diagrams according to an embodiment of the present invention,

5a to 5f exemplary block diagrams to illustrate an operation according to an embodiment of the present invention,

6a to 6f exemplary block diagrams to illustrate an operation according to an embodiment of the present invention,

7 a block diagram according to an embodiment of the present invention,

8a to 8f exemplary block diagrams to illustrate an operation according to an embodiment of the present invention,

9a to 9f exemplary block diagrams to explain an operation according to an embodiment of the present invention, and

10 a block diagram according to an embodiment of the present invention.

in the Following are exemplary embodiments of the present invention Invention explained. In the different characters can identical or similar units, modules, devices etc. have the same reference number.

As it is more detailed below it is explained can embodiments to provide arbitration for the present invention using a plurality of arbitrators or sub-arbitrators becomes. The plurality of sub-arbitrators may be in a hierarchical Architecture can be arranged and in a pipeline operation or operate a non-pipeline operation, as described below Reference to the attached figures described in more detail becomes.

With reference to 1 For example, a basic block diagram of one embodiment of the present invention includes a plurality of requesters 100 that come with a plurality of inputs 102 an arbitration system 102 are coupled to requests to the arbitration system 102 transferred to. An exit 102b of the arbitration system 102 is with a shared resource 104 coupled to allow data transfer from the requester who has been granted access to the shared resource.

As will be explained in more detail below, the arbitration system 102 According to embodiments, a plurality of arbiters or sub-arbiters may be operable in both pipelined and non-pipelined operation. The plurality of arbitrators may be implemented in a hierarchical architecture.

The majority of requesters 100 can include any device, unit, circuit, etc., which is the resource 104 with one or more devices, units, circuits, etc. shares. The majority of requesters 100 For example, memory controllers, processors and process resources including dedicated processors, bus controllers, network controllers including wired network controllers, wireless network controllers, Ethernet network controllers, etc., shared buses, shared memory resources including cache memory, DRAM memory, application acceleration units, data acquisition devices, etc.

The Plurality of requesters may comprise only one type of requestor, For example, only a plurality of processors of the same Type, or may include different types of requestors, for example Processors and dedicated processors.

The shared resource 104 may be any device unit, circuit, etc. that may be shared with more than one device, unit or circuit, etc. The shared resource may be, for example, a memory, a bus, a data port, a data channel, etc. According to embodiments, the plurality of requesters and the shared Resource form a master-slave system in which the plurality of requestors master of a same or different type and the shared resource is a slave.

With reference to 2 An embodiment of an arbitration system will be explained in more detail below.

2 shows an exemplary implementation of the arbitration system 102 in a hierarchical arbitration architecture according to an embodiment of the present invention. The hierarchical arbitration architecture includes a plurality of arbitration nodes 200. , The majority of arbitration nodes 200. is arranged in different hierarchical levels, such that each of the arbitration nodes 200. is associated with a level of the hierarchical arbitration architecture. An arbitration node associated with a level is hierarchically downlinked to the outputs of one or more arbitration nodes of a subordinate level and hierarchically uplinked to a higher level arbitration node. The lowest level arbitration nodes are connected to the requestors.

As it is in 2 As can be seen, the arbitration nodes form a tree-like structure in which each node is coupled to a higher-level node except for the highest-level arbitration nodes, that is, the arbitration nodes at the top of the hierarchical architecture are at the output 102b of the arbitration system 102 coupled. Furthermore, the Ar bitrierungsknoten 200. at the lowest level (level 1) with the entrances 102 of the arbitration system 102 coupled. Each arbitration node 200. At the lowest level may be with one or more of the requester 100 be coupled to request signal from each of the requester 100 to recieve.

While 2 It should be noted at this point that the number of levels and the number of arbitration nodes within a level may be different in other embodiments, an exemplary three level implementation in which the first level has five arbitration nodes and the second level has two arbitration nodes. Furthermore, the number of arbitration nodes associated with or coupled to a higher level arbitration node may be different in other embodiments. Further, the number of arbitration nodes associated with an arbitration node at a higher level may be the same for a particular level or different for arbitration nodes of a particular level. With reference to 2 For example, one of the level 2 arbitration nodes is assigned three level 1 arbitration nodes, while the other arbitration node has only two level 1 arbitration nodes associated with it.

According to embodiments which will be explained in more detail below, the hierarchical arbitration system 102 a hierarchical arbitration request architecture and a hierarchical data path architecture include. In order to implement the hierarchical request architecture and the hierarchical data path architecture, each of the arbitration nodes points 200. According to one embodiment, an arbitration request node provided by an arbiter (or arbiter circuit) 300 is implemented, and comprises a data path request node, which according to an embodiment by a multiplexer 302 who in 3 shown is implemented. The arbitrator 300 includes a plurality of inputs 300a according to the number of arbitration nodes at the next subordinate level associated with the respective arbitration nodes, such that each input 300a with a corresponding output of the arbitrator 300 connected at the next lower level. There is also an exit 300b of the arbitrator 300 with an input of an arbitrator 300 connected, which corresponds to an arbitration node of a higher level.

The multiplexer 302 includes a plurality of data path inputs 302a which are coupled to outputs of multiplexers at subordinate levels, and an output 302b which is coupled to an input of a multiplexer on a higher level.

The arbitrator 300 is with a register 304 coupled to store information identifying which of the input ports or input ports used in an arbitration process of the arbitrator 300 compete with each other, grant was granted. The registry 304 is also connected to a control input of the multiplexer 302 coupled to switch the data path according to the information stored in the register. According to embodiments, the multiplexers according to the information contained in the register 304 are stored, switched.

By implementing the arbitration nodes described above 200. in a hierarchical arbitration architecture as in 2 3, a hierarchical arbitration requesting architecture for performing grant decisions in arbitration processes and a hierarchical data path architecture for transferring the data from the requestors receiving grant to the shared resource is obtained.

4a and 4b show exemplary Embodiments of a hierarchical arbitration request architecture and a hierarchical data path architecture. 4a and 4b Each of the level 1 arbitration nodes has four inputs corresponding to the number of requestors M1 ... M12 associated with a respective arbitration node.

The Plurality of arbitrators, the plurality of requesters, and the plurality of multiplexers of the arbitration system can according to embodiments of a be provided single chip. Furthermore, according to embodiments the arbitration system clocked synchronously.

The arbitration system 300 can be completely provided in hardware (hardware circuits on a chip) or partially in hardware and software / firmware. Furthermore, any known arbitration technique may be used by the arbitrator 300 implemented to provide arbitration between the inputs. For example, fair arbitration techniques such as round robin arbitration (RR arbitration), weighted round robin arbitration (WRR arbitration) or deficit round robin arbitration (DRR arbitration) may be performed by the arbitrator 300 be implemented. According to embodiments, the arbitrator 300 have a memory to older active requests that are not yet through the arbitrator 300 are allowed to take into account.

A first exemplary operation of the arbitration system of the 4a and 4b which corresponds to a pipeline operation will be described below with reference to FIGS 5a to 5f and the 6a to 6f explained in more detail.

Of the Pipeline mode of operation corresponds to an operation in which the process, to provide a grant to a particular requester, in a plurality shared by sub-processes, each at one of the arbitrators be performed in the arbitration system.

Everyone Sub-process receives as an input signal, the result of a previous level and leads the associated sub-process. In other words, it will the process in the pipeline from one level to another level passed on, so that through the last sub-process the entire Process, that is the total arbitration for the request that the highest Level reached, finished.

Of the Pipeline operation is in a hierarchical arbitration system carried out, at a given cycle at each level of the hierarchical Arbitration system an arbitration between the inputs of the Arbitrator is performed.

Based on a grant given by one arbitrator to one of the input signals, a signal, i.e. a pipeline request, is transmitted as an input to a next higher level arbiter where it competes with other input signals from other arbitrators. In a next cycle, the arbiter at the next higher level then arbitrates on the basis of the requests that are active for that arbiter, that is, based on the requests that were received and / or stored by the arbiter. The branch granted by the arbiter is stored in the corresponding register. As the arithmetic time for an arbiter increases significantly with the number of inputs, the arithmetic computation time requirements of each arbiter to terminate arbitration are reduced within one clock cycle in the pipelined hierarchical arbitration system, compared to providing a single arbitrator for all requesters. This allows, for example, an operation in which there are many requesters and short clock periods. The pipeline operation will be described below with reference to FIGS 5a to 5f and 6a to 6f , which show an exemplary pipeline operation, explained in more detail.

5a Figure 4 shows the arbitration request architecture on a cycle 0 in which all of the plurality of arbitrators are idle, for example, after a commissioning. It should be noted that in the following figures, the inputs of the arbiters A11, A12 and A13 are labeled on the first level corresponding to the number of requestors coupled to the input, that is, the arbiter A11 has the inputs 1 to 4 The arbiter A12 has inputs 5 through 8 and the arbiter A13 has inputs 9 through 12. For arbiters A21, A22 and A31, all of which have two inputs in the described embodiments, the first input is labeled 1 and the second one marked with 2 as it is in 5a you can see.

At cycle 1, the requestor M2 and the requestor M7 both issue a request signal to the respective inputs of the arbitration system level 1 arbitrators A11 and A12. During cycle 1, arbiter A11 performs an arbitration process and grants grant to the request of the second input corresponding to M2, since no further request for arbiter A11 is active in cycle 1. Similarly, during cycle 1, arbitrator A12 performs an arbitration process and issues a request to the second input corresponding to M7 Grant, since there is no further request active for arbiter A12 in cycle 1. After arbitration, for example at the end of cycle 1, the result indicating which input has been granted a grant, i.e. 2 for the arbiter A11 and 7 for the arbiter A12, is written to the registers which are the arbiters A11 and A12 correspond to how it is in 5b indicated by arrows. It should be noted that the information contained in the 5a to 5f are shown for a respective cycle which is information currently valid at the end of the cycle. This information will then be present at the appropriate multiplexer at the beginning of the next cycle to allow for data transfer commensurate with the information in the next cycle.

In addition there each of the arbitrators A11 and A12 sends a request signal to an arbitrator A21 the next higher Stage off, which in the next cycle is arbitrated. The granted Request drops doing one step further in the hierarchical system.

With reference to 5c At cycle 2, arbiter A21 has two active requests corresponding to the inputs coupled to arbiters A11 and A12. The transmission of the requests from the arbitrators is indicated by arrows in the figures. As it is in 5a and 5b 1, an inter-cycle arrow indicating the transmission from the arbiter A11 to the arbiter A21 is shown due to the pipeline operation.

In the arithmetic process of cycle 2 is given by the arbiter A21 the request a grant that comes from the arbiter A11 and the information that the granted input signal corresponds, that is 1, is stored in the register A21 after the arbitration is finished, for example at the end of the cycle. A request signal is then applied to arbiter A31 by arbiter A21 the next higher Level output. Furthermore, in the cycle 2, new requests are made the requestors M1, M6 and M9 to the arbiters A11, A12, A13, respectively and in the arbitration process of the respective arbitrators granted. At the end of cycle 2 will be information regarding the granted requests transferred to the corresponding registers.

In the next cycle 3, the in 5 3, the request issued by arbiter A21 has been transmitted to arbitrator A31 at the top level and is therefore an active request at the input of arbiter A31 coupled to arbiter A21. Arbiter A31 grants this request because there are no more requests for this cycle active. Further, new requests from requestors M4 and M8 are received at arbiters A11 and A12 and granted in a respective arbitration process.

at Arbitrator A21 has both inputs which correspond to A11 and A12, active inquiries. It should be noted here that the active request at the entrance, which corresponds to A12, is an old request that already was active at cycle 2, the request being in the arbitration process of the Cycle 2 was not granted to the arbiter A21, while the Request at the entrance, which corresponds to A11, is a new request, those transmitted by A11 has been. The arbiter A21 performs Arbitration between requests and grants the grant Input corresponds to the A12, reducing the active request from A12 initiated is removed. Furthermore, the arbiter A22 leads in Cycle 3 arbitrates and grants the only active request from A13. As already described above, each of the arbitrators after granting a request signal to the next higher level, unless an older one Request blocking the output of the request to the next level, like it will be described below.

Furthermore, in cycle 3, new requests are issued by the requestors M1 and M6 to the arbitrators A11 and A12. It is to be noted that the arbiter A11 performs arbitration in cycle 3, while the arbiter A12 is blocked for arbitration in this cycle, indicated by a gray color of the arbiter 12. Arbiter A12 is blocked because only one request at a given time can be active on an input. The request granted by the arbiter A12 in the previous cycle 2 therefore can not be transferred to the arbiter A21 since the arbiter A12 has not granted the active request at the input corresponding to the arbiter A12 in the previous cycle and This old request is therefore still active on the arbiter A12. Instead of outputting the request to the next level, the request is maintained at the output of the arbiter A12 in cycle 3, as shown in FIG 5d is displayed. Still referring to 5d For example, the information stored in the register of A12 is not changed since no arbitration was performed in the arbiter A12. In the registers corresponding to the arbiters A11, A21 and A31, the information stored in the respective registers is updated at the end of the cycle according to the input signals granted by the respective arbiters.

Referring now to Cycle 4, which is in FIG 5e is shown, new requests are received from the requestors M2, M7 and M10 at the arbiters A11, A12 and A13. Further, the request to the arbiter A12 is out of M8 in the cycle 3 was still active because no arbitration was performed by arbiter A12 in cycle 3. The arbitrator A12, therefore, arbitrates between the requests of M7 and M8 and grants the request M8 a grant, as shown in FIG 5e is shown.

Further the request from the arbiter A12 which was in cycle 3 the output of the arbiter A12 was now closed transferred to the corresponding input of the arbiter A21, while the those not granted in cycle 3 old request at the input, which corresponds to A11, is still active.

As a result of the above, the arbiter A11 could not transmit the request from A11 to A21 and therefore the request is maintained at the output of the arbiter A11, as shown in FIG 5e with the arbiter A11 blocked in this cycle.

Of the Arbiter A13 having only one active request from M10 granted this request. The arbiter A31, which in cycle 4 at all inputs Requests the request at the entrance belonging to A21.

In cycle 5, the in 5f is shown, new requests are received from requestors M1, M6 and M9. Arbiter A12, which now has active requests from all ports, arbitrates and grants the grant to the input coupled to A11. The arbiter A21, which has an active request from the arbiter A13, grants the input grant associated with the arbiter A11, and the arbiter A31, which has two active requests A21 and A22, grants the input, which is A22 is coupled.

It should be noted that in pipelining for an n hierarchical level arbitration system, at least n cycles are required for a request to pass through the pipeline, as each of the arbitrators at one level wait for the lower level arbiter input Has. Therefore, in the above example, the first data transfer from a requester, that is, the requester M2, to the shared resource starts at a cycle n + 1, that is, at the cycle 4 in the above example. It is further noted that the in the 5a to 5f only shows exemplary pipelined operation, with other ways to implement the pipelined operation of the arbitrators.

The data transfer in the hierarchical data path system, which in 4b is shown by the requestors, which was granted by the system grant, to the shared resource is now referring to the 6a to 6f described.

6a shows a data path system at cycle 1. It should be noted that 6a at cycle 1 starts while 5a shows the arbitration request system at cycle 0, taking into account here that data can only be processed after being granted by the entire system only one cycle later. At cycle 1, all multiplexers are in an idle or indefinite state because at the beginning of cycle 1 no information is stored in the registers that would allow the multiplexers to perform a corresponding switch. Referring to cycle 2, which is in 6b is shown, the register associated with A11 contains, at the beginning of cycle 2, the information identifying the input 2 as the input which has received a grant, as determined by comparison with the information contained in the in 5b stored registers are shown, can be seen. The multiplexer D11 therefore places its second input in an active state. Further, at the beginning of cycle 2, the register associated with A12 has the information identifying the input 7 as the granted input, and the multiplexer D12 places the input corresponding to M7 in an active state. The setting of the multiplexers D11 allows data from M2 to be transmitted one level further in the system, that is, to the input of the multiplexer D21 as shown in FIG 6b is shown. In addition, setting the multiplexer D12 allows data to be transferred from M7 to the corresponding input of the multiplexer D21.

In the cycle 3, the in 6c is shown, the input corresponding to M1 is put in an active state in the multiplexer D11, the input corresponding to M6 is set in an active state in the multiplexer D12, and the input coupled to D11 becomes in the multiplexer D21 in an active state, this being in accordance with the information stored in the registers, cf. 5c , In addition, in the multiplexer D13, the input corresponding to M9 is set in an active state. The data of M2 are transmitted one level further in the hierarchical data system, in accordance with the setting of the multiplexer D21, that is, from the input of the multiplexer D21 to the input multiplexer D31 as shown in FIG 6c is shown. The data from M1 is transferred to the input of the multiplexer D21 according to the setting of the multiplexer D11. It should be noted that data is not transferred from D12 to D21 since the old data M7 is still active at the input of the multiplexer D21.

In cycle 4, the in 6d is shown For example, the multiplexers are set in accordance with the information stored in the respective registers (see 5c ). It is in 6d to recognize that with the setting of the multiplexer at the highest level, a data path corresponding to a branch through the hierarchical data path system, that is, a data path from the requester M2 to the shared resource, is completed. Data from the requester M2 is therefore transferred to the shared resource in this cycle.

dates of M7 are further from the multiplexer D21 to the multiplexer D31 in accordance transmitted with the setting of the multiplexer D21 while data from M6 to the input of the multiplexer D21 and data from M9 to the Input of the multiplexer D22 transmitted become.

In cycle 5, which is in 6e Finally, data from M7 is transferred to the shared resource while the data from M1, M4, M9 and M10 each advance one level further in the data path.

In the cycle 6, the in 6f is shown, data is transferred from M9 to the shared resource, while data from M10 and M9 are transferred one level further in the pipeline, i.e., from multiplexer D22 to the input of multiplexer D31 and from multiplexer D13 to the input of the multiplexer M22.

As it has already been described above, it is required in the pipeline operation at least n cycles for a request to cross the pipeline. In embodiments of the present invention which will be described below can that Arbitration system not only capable of a pipeline operation to deliver, but are also capable to provide a fast arbitration when needed.

In Embodiments, described below, the arbitration system may have a selective non-pipeline arbitration of a request in at least provide some of the arbitrators when needed. The non-pipelined arbitration may be a parallel arbitration be and can be chosen when arbitrators are in an idle state, as follows is described. In a parallel arbitration, one is specific Request from a requester or a specific request from an arbitrator a lower level concurrent with more than one level, this means more than one arbitrator of the path corresponding to the request (the Paths the request has to take) decide within one Clock cycle (parallel), whether this request is granted or whether another Request granted becomes. It should be noted that in the pipeline operation the grant for a request at a given time or cycle, only one at a time Level of the system, and if the request grants a grant will, the request progresses one level further, where a decision in the next Cycle performed becomes. According to embodiments the arbitration system is operated in a parallel mode when one or more arbitrators in the cycle previously in an idle state were, that is did not arbitrate requests in the pipeline operation.

To selectively operate the arbitration system in a parallel mode of operation are the arbitration nodes 200. , in the 3 are modified in order to have a circuit arrangement which makes it possible to provide parallel or almost parallel feeding of the requests to the different levels. At the same time, it should be interpreted broadly so that the delivery of the requests to the different levels need not take place exactly at the same time but within a time interval that is short compared to the cycle time duration or at least less than the cycle time duration. According to embodiments, the circuitry may be formed by combinatorial circuitry, such as OR logic components, AND logic components, etc., which allows the request signals to be forwarded in a short time.

7 FIG. 12 shows an exemplary implementation for providing parallel delivery of requests to the various levels. In contrast to 3 has the arbitration node 200. in 7 an OR logic component 306 on. The OR logic component 306 has a plurality of inputs, each input associated with one of the next lower level arbitration nodes associated with the arbitration node 200. are assigned. Like it out 7 the arbitration node points 200. in addition to the entrances 300a connected to the outputs of the lower level arbitrators, second inputs 300c on. The inputs 300c are connected to nodes that are connected to the inputs of the OR logic component 306 and are connected to second inputs of the arbiter. Signals coming to the second inputs 300c be applied, are parallel to the second inputs of the arbiter 300 and to the inputs of the OR logic component 306 delivered.

By the arbitration node, which in 7 2, two signals are therefore transmitted in the hierarchical arbitration request system. The first signal transmitted from one level to the next higher level is based on an arbitration process at the subordinate level, as already described with reference to the 3 . 4 . 5a to 5f and 6a to 6f has been described. The first signal therefore corresponds to a pipeline operation and is referred to below as a pipeline signal or pipeline request. The second signal is a signal as well as the arbiter 300 however, the same is transmitted by the combinational circuit arrangement in parallel, that is within a short period of time, to at least one further level. The second signal may therefore be regarded as a look-ahead signal or a look-ahead request and will be referred to hereafter. The second signal, which represents an OR function of all inputs, is therefore supplied when one or more signals are received at the input, may be considered as a signal indicating in a fast, higher level fashion that it is on that branch will give an activity that will allow the higher level to already begin arbitrating before getting the pipeline request.

The arbitration node 200. according to 7 therefore has two nodes in the arbitration request section. A first node is through the plurality of first inputs 300a of the arbitrator 300 implemented to receive the first signals from subordinate arbitration nodes, wherein the first node is further represented by the output 300b of the arbitrator 300 is implemented to transmit a signal to an arbitration node at a higher level. A second node is through the plurality of inputs 300c implementing the second signals from second nodes of subordinate arbitration nodes, the second node further being through the output 300d implemented to transmit the look-ahead request to a higher-level arbitration node.

As the arbitrator 300 according to 7 for each slave arbitration node associated with the arbitration node, receiving two signals, that is, the pipeline request and the lookahead request, the arbitrator in operation makes a decision as to which of the requests are valid requests, or which of the requests are considered for arbitration ,

According to one embodiment, the pipeline requests are prioritized absolutely against the lookahead requests. In other words, if a pipeline request from one of the inputs 300a is received, or if a pipeline request is active due to an un-granted legacy pipeline request, all look-ahead requests are discarded or disregarded in the arbitration at that arbitration node. However, because the look ahead signals are transmitted to several other levels along the branch of the hierarchical system, the lookahead signal may be considered at other levels where no pipeline request is active.

consequently is arbitration of pipeline requests absolutely prioritized over one Arbitration of the preview requests, such that only between However, other pipeline requests can not be arbitrated Pipeline requests and look-ahead requests, and where look-ahead requests can only be arbitrated with each other, if this for an arbitration allowed are. In other words, look ahead inquiries discarded when a pipeline request to one of the inputs of a each Arbiter is created. This assures that that hierarchical system works in a pipeline mode of operation when the pipeline is filled with pipeline queries, where the hierarchical System works in a parallel mode of operation, if some or all of the arbitrators are idle or no active pipeline request exhibit.

It should be noted that in addition to the strict separation of look-ahead requests and pipeline requests described above in the arbitrator 300 , other ways of operation may be provided in other embodiments, wherein look-ahead requests and pipeline requests may be mixed in an arbitration, for example by giving the look-ahead requests a lower priority.

It should also be noted that pipeline requests are always at the output 300b of the arbitrator 300 when arbitration has been performed in the arbitrator, whereupon the pipeline request is transferred to the next higher level arbiter as previously described. However, if the next higher level arbitrator has granted a lookahead request in the previous cycle for that input, the pipeline request is discarded in the next cycle to avoid arbitration of duplicate requests.

Subordinate arbitrators directly receive requests from the requesters. Instead of a coupling of the outputs 300a with the requestors, for the lowest-level arbitrators, the input is 300b coupled to the requestors to receive the requests and generate look-ahead signals and to deliver them in parallel with the arbitrator for arbitrating the request. Therefore, for the low-level arbitrators, the input 300a not be provided or disconnected.

In order to give a better understanding of the above-described lookahead implementation, the example given in the following is given below 5a to 5f and 6a to 6f was given in the 8a to 8f and 9a to 9f applied to the lookahead implementation described above.

8a begins at cycle 0 with the system in an idle state. In 8b In the arbiters A11 and A12, in the cycle 1, requests from the requests M2 and M7 are received. Due to the lookahead mechanism, the lookahead signals are transferred from Arbiters A11 and A12 to A21 and from Arbiters A21 to Arbiter A31. In other words, in the cycle 1, the preview signals are transmitted to all levels of the hierarchical system. It should be noted that the look-ahead signals (look-ahead requests) in the figures are indicated by circles, while the pipeline requests are indicated by a diamond.

The Requests from requestors M2 and M7 are at the arbiters A11 and A12 are the only active requests and are therefore granted. at Arbiter A21 has two look-ahead requests from A11 and A12 active. Since no pipeline request is active, the two look-ahead requests performed an arbitration and receipt 1, which corresponds to A11, granted a grant. at Arbitrator A31 is the only one ahead of A21 active request and therefore the first input corresponding to A21 is a grant granted.

In the cycle 2, the in 8c is shown, requests from the requestors M1, M6 and M9 are received at the arbitrators A11, A12 and A13 and granted a grant for the same, since no further requests to the respective arbitrators are active. Look-ahead requests are generated for each requester M1, M6 and M9 and provided by the respective branches, that is, to the arbitrators A21 and A31 for M1 and M6 and to the arbitrators A22 and A31 for M9. With regard to the arbiter A21, three requests are still active in cycle 2. Two look-ahead requests and one pipeline request. The pipeline request at the arbiter A21 is a request corresponding to the request of the requester M7 in the previous cycle. It should be noted that no pipeline request was valid for arbitration in the previous cycle at arbiter A11, since the request from A11, that is, the lookup request from A11 corresponding to the request from M2, already grants in the previous cycle has been. Since the arbiter A21 now contains an active pipeline request, the pipeline request is prioritized over the look-ahead requests and given grant 2 to the input. The look-ahead request of M9 is granted grant in the arbitrators A13 and A22, as in 8c is shown. Further, in the arbiter A31 in which two look-ahead requests of A21 and A22 are active, the input 1 corresponding to A21 is granted arbitration in the arbitration.

In the cycle 3, the in 8d is shown, requests from the requestors M4 and M8 are received at the arbiters A11 and A12, respectively. Look-ahead requests are transferred to arbiters A21 and A31. The arbiter A21 has four requests in the cycle 3, two look-ahead requests and two pipeline requests each from A11 and A21. In accordance with what has been described above, the pipeline requests are prioritized, and therefore an arbitration is performed between the two pipeline requests, granting the first input.

Of the Arbitrator A31 has two pipeline requests from Cycle 3 in cycle 3 Arbiter A21 and A22 and a preview request on. An arbitration will performed between the pipeline requests, the second input granting is granted. It should be noted that in cycle 3, a mere pipeline operation is done, since each of the arbitrators, in the cycle 3, an arbitration carry out, arbitrated between pipeline requests.

In Cycle 4 will be new requests to the arbitrators A11, A12 and A13 received by the requestors M2, M7 and M10, respectively. Forward-looking requests are transmitted to arbitrators A21 and A31 for requests from M2 and M7 and look-ahead requests become the arbitrators A22 and A31 for the request transmitted by M10. In this cycle, all arbitrators A21 and A31 have active pipeline requests, thus, the foresight requests of M2 and M7 are out of the question to be pulled. For the branch corresponding to M10 is accepted for the request of M10 the look-ahead requests based on this request are granted by grant allows the arbiters A13 and A22 in one cycle, since the arbitrators A13 and A22 were in an idle state in the cycle 3. It is Note that the look-ahead request from M10 is at arbitrator A31 is discarded because at the input 1 an active pipeline request is present. As the look-ahead requests from M10 by the arbitrators A13 and A22 grant are issued, the request proceeds in two stages in one cycle down the pipeline. Arbiters A13 and A22 carry one parallel operation with respect to the request from M10. Compared to a pure pipeline operation, at the grant only the arbiter A13 for This request would be issued within the cycle, the Request gained a stage in the pipeline.

With regard to the arbiter A21 is to be noted Note that the pipeline request resulting from the arbitration in the previous cycle (cycle 3) could not be transferred to the corresponding input of the arbiter A31 because the request is still active at the arbiter A31, since there is no such input in the previous cycle Granted.

The Output request from cycle 3 will therefore be at the output of the arbiter A21 is maintained, and the arbiter A21 becomes this cycle for the Arbitration blocked, as indicated by the gray color. additionally is the arbiter A12 for an arbitration is blocked in this cycle because the input of the Arbiter A21 corresponding to A12 in the preceding one Cycle no grant was granted.

The arbiter A11, which has received a new request from the requester M2, performs a normal arbitration granting this request, as in 8e shown.

In cycle 5, which is in 8f is shown, requests from M1, M6 and M9 are received and corresponding look-ahead requests are generated. Since the arbitrators A21 and A31 have active pipeline requests, the look ahead signals of M1 and M6 are not taken into account in the arbitration. Regarding the request from M9, the look-ahead request from M9 is granted by both arbiters A13 and A22 because arbitrator A22 has no active pipeline request.

It It should also be noted that in cycle 5 the arbiters A11 and A12 are blocked because the arbiter A21 in the previous one Cycle was blocked, causing active pipeline requests to the input of the arbiter A21 is not removed in the previous cycle could be to enable that new requests forward stride. Therefore it is for the pipeline request that is at cycle 4 at the output of the arbiter A21 is not yet allowed to the arbitrator Transfer A21 to become. Furthermore, the request from M2 was granted in the cycle grant, at the end of cycle 4 is not transferred to arbiter A21 since the old request is at the input 1 of the arbiter A21 due to the blocking of the arbiter A21 in the previous one Cycle still pending is.

Of the Arbitrator A21 performs while Cycle 5 normal arbitration between pending pipeline requests by, corresponding to the input 2 corresponding to A12 in the arbitration process granting is granted.

9a to 9f now show the data path system for the operation described above. As can be seen, in cycle 1, the multiplexers are in an idle state or an undefined state since no information from granted inputs is stored in the registers. In the cycle 2, the multiplexers are set in accordance with the stored information in the respective registers (compare with the information stored in the register at the end of the previous cycle, that is, in the cycle 1 shown in FIG 8b is shown), allowing data transfer for the requester M2 through all levels to the shared resource within one cycle. Further, according to the setting of the multiplexer D12, data of M7 is transmitted from the requester M7 to the input of the multiplexer D21 during the cycle 2.

In cycle 3, the multiplexers are updated according to the current information in each of the registers (see 8c ). As it is in 9c As can be seen, data from M7 is transferred from the input of the multiplexer D21 to the shared resource during this cycle. Further, data from M1 and data M6 is allowed to pass through the pipeline to the respective inputs of the multiplexer D21 during this cycle. In addition, data from M9 is transferred from the requestor M9 to the input of the multiplexer D31 during cycle 3.

In cycle 4, which is in 9d 3, the multiplexer D31 is switched to input 2, thereby allowing data from M9 to be available at that input to be transmitted to the shared resource. Further, data from M1 passes through the pipeline from the input of the multiplexer D21 to the input of the multiplexer D31, and data from M4 proceeds from the requester M4 to the input of the multiplexer D21. The data from M6 are not transmitted in this cycle and are still available at the input 2 of the multiplexer D21.

In cycle 5, which is in 9e 3, data from M1 is transferred from the input of D31 to the shared resource, data from M4 being transferred from the input of multiplexer D21 to the input of multiplexer D31. Further, data from M2 is transmitted from the requester M2 to the input of the multiplexer D21. The data from M6 will still not be transferred. In addition, data from M10 is transmitted from the requester M10 to the input of the multiplexer D31. It should again be noted that data from M10 is transmitted over more than one level in the hierarchical system.

In the cycle 6, the in 9f is shown, data from M4 is transferred from the input of D31 to the shared resource and the data of M6 are transferred from the input of the multiplexer D21 to the input of the multiplexer D31. Further, data from M9 is transmitted from the requester M9 to the input of the multiplexer D22.

Comparing the data transfer operation described with reference to FIGS 9a to 9f is described with the data transfer operation, with reference to the 6a to 6f is described, it can be noted that in the operation according to the 9a to 9f the data transfer already begins at cycle 2, whereas in pure pipeline operation the system requires n-1 cycles, ie two more cycles, after the system idles. It is a general feature of the embodiment described above that, after an idle state of the system, regardless of the number of levels of the hierarchical architecture, the first grant decision can be made due to the parallel operation within one cycle, whereby data can already be transferred to the next cycle ,

The embodiment described above therefore overcomes idle times of the pipeline due to arbitrators in an idle state by generating look-ahead requests along a respective branch of the hierarchical system for each request received from a requester. Another modification may be obtained according to one embodiment by generating the lookup requests for each request from a requester and for each pipeline request. This allows to bridge gaps (idle states) of the pipeline in the middle of the pipeline. The above operation may, in one embodiment, provide a further input to the OR component in addition to the plurality of inputs 300c be delivered, with the further input to the output 300b is connected, as in 10 shown.

Claims (27)

Method with the following steps: Operate a plurality of arbitrators in a pipeline mode; and Operate at least a portion of the plurality of arbitrators in a non-pipelined operation. Method according to claim 1, wherein the pipeline mode comprises the following steps: Deliver a first signal from a first arbiter to a second one Arbitrator based on an arbitration at the first arbitrator; and wherein the non-pipeline operation comprises the steps of: Deliver a second signal to the second arbiter independent of an arbitration at the first arbiter; and arbitration at the second arbiter based on the second signal. Method according to claim 2, in which the second signal in the pipeline mode and the non-pipeline operation in which an arbitration is provided in the pipeline mode is prioritized to the second arbiter based on the first signal via a Arbitration based on the second signal. Method according to claim 2 or 3, wherein the plurality of arbiters comprises a plurality of Arbitrators of a hierarchical Arbitrierungssystem are, where the first signal is a pipeline request signal and the second signal a look-ahead signal, and wherein the operation is in the pipeline mode Deliver the pipeline request signal from the first arbitrator a first input port of the second arbiter based on the arbitration between the plurality of input ports on the first arbitrator, wherein the second arbiter on a parent Level is implemented compared to the first arbitrator; and in which the non-pipeline operation includes the following steps: Deliver the look-ahead signal to a first input port of the second Arbitrator on a parent Level, wherein the look-ahead signal is independent of an arbitration at the first arbiter; and delivering a third signal, the one grant for the indicates the first input port based on the look-ahead signal. Method according to one the claims 1-4, wherein the at least a portion of the plurality of arbitrators operated in a non-pipeline operation, if the at least a part of the plurality of arbitrators in the previous cycle is in an idle state or none in the previous cycle has active pipeline request. Method according to one the claims 1 to 5, wherein the non-pipelined operation performing a parallel Arbitration of a request from at least one requester of a plurality of requestors. Method according to one the claims 1 to 6, further comprising the step of: Save from information for each of the plurality of arbitrators, the information being those gates indicated by a respective one of the plurality of arbitrators granting was granted. A method according to any one of claims 1 to 7, further comprising the step of: Providing a data path from a requester to a shared resource based on the information stored for a respective arbiter of the plurality of arbitrators. Method according to one the claims 1-8, wherein in the pipeline mode one request per clock cycle advances one level, and wherein in the non-pipelined operation a request advances at least two levels of the pipeline per clock cycle. Method according to claim 9, where the request in the non-pipelined operation all levels of the pipeline advances within one clock cycle. Method according to one the claims 1-10, wherein a requestor is through the plurality of arbitrators granting for one Data transfer to a shared resource within one clock cycle after the requestor to grant a request to the plurality of arbitrators issued when the plurality of arbitrators is in an idle state. Arbitration nodes in a hierarchical arbitration system, wherein the arbitration node comprises the following features: one first node, the first node having a plurality of first inputs, to receive first signals from a subordinate arbitration node received and having a first output to a signal to a Arbitration node of a higher Transfer level; and a second node, the second node having a plurality from second inputs to second signals from second nodes of subordinate arbitration nodes and a second output to signal a parent Arbitrierungsknoten to transfer. The arbitration node of claim 12, wherein the second Node combinational hardware logic has. The arbitration node of claim 13, wherein the combinational Hardware logic is implemented to provide a plurality of input signals, at the second entrances are received, combine, and at the output an output signal according to an OR combination of the input signals. Arbitration node according to one of claims 12 to 14, wherein the arbiter is coupled to a register, the associated with the arbitration node to store information, referring to the input granted by the arbitrators. Arbitrator system with the following features: one first arbitrator; a second arbitrator; a third arbiter; a first connection to a first signal from a first requester of a plurality of requestors to the second one To transfer arbitrators; one second connection to a second signal from a second requester the plurality of requestors to transmit to the first arbitrator; one third connection to a third signal based on the first and transmit second signal to the third arbiter; one fourth connection to a fourth signal from the first arbiter to transmit to the third arbiter; and a fifth Connection to a fifth Signal from the second arbiter to the third arbiter. The arbitrator system of claim 16, wherein the arbitrator system is a hierarchical arbitrator system, the first and second Arbitrators are assigned to a hierarchical level, and where the third arbitrator of a different hierarchical level, assigned to a hierarchical level is. An arbitration system according to claim 16 or 17, wherein the third connection has combinatorial hardware logic, wherein the combinational hardware logic comprises first and second Having an input and an output for outputting the third signal, and being the fourth and fifth Connection each have a register to the fourth and fifth signal store, with the register having a control input of a multiplexer is coupled. Arbitrator system according to one of claims 16 to 18, the system further comprising: one Data path containing the first requester and the second requester a shared resource, the data path to the multiplexer is coupled to selectively data based on those in the register to transmit stored signals. Arbitrator system with the following features: one A plurality of arbitrators, wherein the plurality of arbitrators are formed is to be operated in a pipeline operation, and wherein at least a part of the plurality of arbitrators is formed, to operate in a non-pipelined operation. The arbitrator system of claim 20, wherein the at least one of a portion of the plurality of arbitrators in a non-pipelined operation is operated when the at least a part of the plurality of Arbitrators is in an idle state. An arbitration system according to claim 20 or 21, wherein the plurality of arbiters is configured to, when the Plurality of arbitrators originally is in an idle state, a data transfer for one Inquirer one clock cycle after the requester with respect to one Access has made a request to trigger. Arbitrator system according to one of claims 20 to 22, wherein the plurality of arbitrators is a hierarchical arbitration system forms. Arbitrator system according to one of claims 20 to 23, wherein each of the plurality of arbitrators with a corresponding Register is coupled to store information, the gates which are granted by the majority of arbitrators has been. The arbitrator system of claim 24, wherein the corresponding one Register is coupled to a corresponding multiplexer to a data path from a requester to a shared resource based on providing information in each of the corresponding Register are stored. The arbitrator system of claim 25, wherein the plurality is configured by arbitrators to enter in pipeline operation first signal from a first arbiter to a second arbiter on a next higher Level based on arbitration in the first arbitrator and wherein in the non-pipelined operation a second Signal to the second arbitrator regardless of the arbitration in the first arbiter is delivered. The arbitrator system of claim 26, wherein the second Signal is further supplied in the pipeline operation, and wherein an arbitration based on the first signal is prioritized via a Arbitration based on the second signal.