Dynamic strict priority arbiter


The dynamic priority arbiter enables the priorities of the requestors to be changed during arbiter operation, allowing different parameters such as congestions, waiting time, data size etc… to affect the requestor’s priority. The arbitration between requestors of equal priority is using either a strict priority based on requestor ID or round robin arbitration. The arbiter implements a two-step arbitration process. The first is a fixed priority arbitration based on the valid priorities of the requestors. Once the highest priority with available requestors is selected, the second stage of arbitration selects between those requestors of the same priority by strict priority using their requestor ID or by round robin.

Block diagram

The basic block diagram shows the dynamic priority arbiter.

Dynamic priority arbiter block diagram


  • Dynamically changeable priority per requestor.
  • Strict priority according to request ID or round robin among equal priority requests.

Optional features

Optional features available through different file download

  • synchronous and asynchronous reset.
  • Type of second stage arbitration, either strict priority or round robin.

Product Deliverables

  • verified RTL code
  • Access to detailed design documentation
  • 1 year support and customization service

parameters table

parameters for typical FIFO


Valid values




Number of requestors



0 – ceil (log(WIDTH)) binary encoded index of the     granted requestor.

1 -  WIDTH one-hot encoding of the granted requestor

2 – WIDTH thermometer encoding of the granted requestor, all bits lower than the selected are 0.

Interface table

Signal name






Indication that the current grant is valid and is a result of a valid requestor.


Input [WIDTH – 1:0]

Request input vector


Output [WIDTH – 1:0]

Grant output, either binary decoded or one-hot.

In case of binary decoding the width of the grant would be log2(request WIDTH) rounded up.

priority0..(WIDTH – 1)

Input [log2(WIDTH) – 1:0]

The number of priority vectors is equal to the number of requests where each priority vector has the round-up of log2(WIDTH) bits decoding WIDTH priorities.



This implementation allows for on the fly changes to the priority of each requestor so different parameters like aging, queue buildup, data sizes and more, to affect the arbitration process.

The arbiter selects the highest available priority (priority 0 would be the highest priority) and grants all the requestors of the priority before moving to the next priority. In case a higher priority request is asserted, it will be immediately granted, so the arbiter would move to serve the higher priority requestors.

The functionality of the dynamic arbiter is similar to a strict priority arbiter. The first to be granted is the requestor with the highest priority (priority 0 is the highest) and the request ID which is lowest. The advantage of the dynamic arbiter is the option to assign each requestor a priority independent of the other requestors.

Strict priority arbiter

The strict priority arbiter finds the requestor with the highest priority and returns its number.

Round robin arbitration

Round robin arbitration is a scheduling scheme which gives to each requestor its share of using a common resource for a limited time or data elements. The basic algorithm indicates that once a requestor has been serves he would “go around” to the end of the line and be the last to be served again. Please refer to the arbiters section for more information about the work conserving round robin arbiter used in this component.

Test Items

the below table summarizes the test items that were checked for the arbiter

Item name


Check resulting arbiter distribution

Run many requests where all requestors, check to see most grants are to the higher priority requests.

Send constant number of requests through each requestor.

See that higher priority requests are served first.

Set all requests to the same priority

Check that arbitration is done according to request ID.

check round robin functionality

Using same priority for all requestors, expect full round robin distribution.


Integrating with a FIFO system

The typical usage of a dynamic priority arbiter for a FIFO system with multiple FIFOs and an arbiter to select which of them will be extracted is implemented through the following connections:

1.    Connect the request vector to the ~empty or each of the FIFOs so when the FIFO is not empty, a request to the arbiter will be asserted.

2.    Connect a one-hot grant vector (OUTPUT_TYPE=1) to the extract of the FIFOs. This would be masked with the downstream flow control signaling.

3.    Connect the arbiter ack signal to the downstream flow control signal so each time there is no flow control, the ack would be asserted providing that the arbiter valid is asserted.