Arbiters: Order in the Chaos

Welcome to the first blog post of 2026!

This is a topic that I have been planning since 2023…. sorry for being 3 years late 🤪… Anyway, let’s dive right in, without wasting any more time!

One grant to rule them all!

In a digital system, certain resources, for e.g., bus, are shared by multiple masters (also called agents or requesters). These bus masters can request for access any time (Active requesters), often simultaneously. The problem is obvious: Not everyone can be served at once!

So, who resolves this conflict, and how?

In such a chaotic environment, the arbiter brings the order. Acting as a mediator, it observes all incoming requests and deterministically selects one requester to grant access. The decision may be based on priority, fairness, timing, or some pre-determined policy, but the outcome is always the same: A single, unambiguous grant. Yes, one grant to rule them all!

This post walks through some of the popular and interesting arbiters that I cherry picked. The RTL source code of each arbiter is also available in the GitHub.

Design goals

Arbiters are deceptively simple blocks with a bunch of requests and grant signals.

Arbiter as a Black Box

I said “deceptively”, because behind the black box are corner cases, scheduling policies, fairness trade-offs… etc… In fact, their impact in a system is outsized!
Nevertheless, all of them are designed around a set of common fundamental goals or parameters which measure the effectiveness of an arbiter.

• Fairness – Give a fair chance to every requester. No one should have to wait forever!
• Performance – Keep the resource busy, the latency low, the arbitration cycles less.
• Predictability – The scheduling policy followed must be deterministic. Ask yourself: can you bound the worst-case wait time for any requester in the arbiter? If it’s YES, we are good!
• Logical complexity – Arbiters usually sits on hot paths in a system. Choose your arbiter wisely if you don’t want to blow your critical path!

Fixed Priority Arbiter

The Fixed Priority arbiter is probably the simplest and most popular arbiter. In an FP arbiter, each requester is assigned a static priority. It always grants the highest-priority active requester.

An AND gate chain as shown below form the fundamental building block in an FP arbiter with N requesters.

Grant generation at the Nth requester in an FP arbiter

Fixed Priority Arbiter grant timing

These arbiters are commonly used in applications like interrupt controllers, simple SoCs with very few bus masters.

Pros

• Fast, simple, small logic foot print.
• Lowest latency for high-priority requesters.

Cons

• Unapologetically unfair! If high-priority requesters are always active, they will monopolize the resource, and the low-priority requesters will starve.
• The logical and wiring complexity scales up with the number of requesters. The lowest-priority requesters’ grant path could become the critical path.

Time Division Multiplexed Arbiter

The TDM arbiter grants access to a requester only in fixed, pre-defined time slots. The grant is issued regardless of request activity.

In TDM arbiters, every requester is assigned a time slot. The arbiter visits the requester in its time slot. If request is active in that time slot, grant is issued to the requester. Else, the time slot is wasted and it moves to the requester assigned to the next time slot.

A one-hot token is generated every clock in a TDM arbiter

Being fully deterministic, with no priority schemes and no dependencies on request patterns, TDM arbiters find its applications like real-time systems, video/audio processing systems.

With a TDM arbiter, you can also assign weights to requesters by allocating more time slots to certain requesters instead of distributing slots equally. In this way, the bandwidth can be easily distributed among requesters in different ratios. For e.g: If there are two requesters A & B and you want to divide the bandwidth in 1:2 ratio, Assign one slot to A, two slots to B.

Pros

• Zero starvation.
• Extremely fair, guaranteed bandwidth.
• Predictable latency.

Cons

• Wasted bandwidth or time slot if the requester is idle during its turn.
• The latencies can be high and the bandwidth utilization could take a hit in case most of the requesters are idle most of the time.

Classic Round Robin Arbiter

Even though Fixed Priority arbiters are popular in systems where fairness is not a major concern, the Classic Round Robin arbiter is often the first choice when a fair and simple arbitration scheme is required in typical SoC bus interconnects, shared memory access structures etc.

In a CRR arbiter, grants are issued in a rotating circular queue. Once a grant is issued to an active requester, the requester is masked, effectively giving the last-granted requester the lowest priority in the next arbitration cycle. In any arbitration cycle, if the next requester in the queue is inactive, it is skipped, masked, and the next active requester immediately gets the grant. Hence, no arbitration cycles are wasted like in the TDM.

A CRR arbiter can be constructed from two FP arbiters

Pros

• Fair arbitration policy.
• Simple and easily scalable.
• No starvation, no wastage of arbitration cycles.

Cons

• Latency may grow with number of requesters.
• If the work load of the requesters are unequal, CRR arbiter would still treat them equally. This may not be suitable in applications where certain requesters require more bandwidth or lower latency, such as high-throughput DMA engines.

Weighted Round Robin Arbiter

The WRR arbiter is a tweaked version of the CRR arbiter to address the issue of unequal workloads among requesters. It extends the classic round robin scheduling by assigning pre-defined weights per-requester, allowing some requesters to receive multiple consecutive grants. The ones with more weights are issued more grants consecutively.

With this scheme, bandwidth can be easily distributed among requesters in different ratios. For e.g: If there are three requesters A, B, C, and you want to divide the bandwidth in 1:2 ratio-

Assign weights: \text{weightA} = 1, \text{weightB} = 2, \text{weightC} = 3 .

Distributing bandwidth using weights in a WRR arbiter

This arbiter finds its application in network routers, high-priority DMA engines, memory controllers.

Pros

• All pros of CRR arbiter + Bandwidth can be distributed using weights based on the workload requirements.

Cons

• Increased logical complexity compared to CRR arbiters.
• The requesters with bigger weights gets bursty grants and this may lead to increased latency for the requesters with lower weights.
• The weight is statically assigned, so the packet size of the requester during the access should be pre-known, and is assumed to be static.

Interleaved Weighted Round Robin Arbiter

The IWRR arbiter is similar to WRR but grants are interleaved across requesters, instead of issuing them consecutively to a requester. The IWRR arbiter addresses the issue in the WRR arbiter of having more latency for the requesters with lower weights. By making the grants interleaved, the latency is reduced and the traffic becomes more uniform.

The grants are interleaved in IWRR arbiter to reduce latency

Pros

• All pros of WRR arbiter + Better latency behavior than WRR.
• Uniform traffic compared to WRR arbiter as the burstiness of grant is scrapped.

Cons

• Increased logical complexity compared to WRR arbiters.

Deficit Round Robin Arbiter

Although (I)WRR arbiters are fair for most of the applications, they schedule requests under the assumption that a requester’s packet or burst size is constant. As a result, weights are assigned statically among the requesters depending on their packet sizes. If a requester can issue variable-sized packets over different arbitration rounds, this assumption breaks down, and fairness in scheduling begins to erode!

Let’s discuss a simple example of two arbiters A, B, to understand the underlying issue of WRR arbiters and how DRR arbiters can be superior to WRR arbiters in such situations.

\text{A's packet size} = 64\text{-}256 \text{bytes}
\text{A's packet size} = 128\text{-}512 \text{bytes}

In the WRR arbiter, for uniform bandwidth distribution, you may want to assign static weights such that A should be issued twice the number of grants compared to B:

\text{weightA} = 1, \text{weightB} = 2 .

This works fine, say, if the packet size of A and B are 64 and 128 respectively, or 256 and 512 respectively. As long as the packet sizes are always in the weight ratio assumed, the WRR arbiter does its the job fine.

However, if A wants to send 256-byte packet next time, and B wants to send 128-byte packet, B should be issued twice the the number of grants compared to A to preserved bandwidth fairness. But in the WRR arbiter, the bandwidth distribution remains statically tied to the pre-assigned weights, resulting in behavior opposite to what is expected in this situation!

Hence, WRR arbiters preserve fairness only in terms of grant count, not in the actual burst size, which may vary dynamically in some systems.

DRR arbiters can adjust the bandwidth allocation according to the current packet size of the requester. Let’s see how the DRR arbiter handles the above situation.

• For each requester, a Quantum (Q) is defined. The quantum represents the amount of credit (in bytes) added to a requester in every arbitration round.
• A requester becomes eligible for a grant only when its accumulated credit is sufficient to service the pending packet, i.e., when C > P
• Every arbitration round, an active requester accumulates credits equal to its quantum, i.e., C = C + Q .
• Credits are consumed based on the actual packet size when a grant is issued, i.e., C = C - P on every grant.
• The grant can be issued as long as C >= P . If the remaining credit is insufficient to cover the next packet, .i.e., C < P the requester is skipped for the current round, and the remaining deficit is carried forward to the next arbitration round as credits.

In this way, even with variable work loads, the bandwidth can be effectively utilized and distributed among the requesters with the DRR arbiter. Because, the DRR arbiter brings fairness in terms of bytes, not grant count.

The DRR arbiter – fairness in dynamic traffic

Some design trade-offs in the DRR arbiter are:

• Quantum size of a requester: One thumb rule is to choose Q for a requester such that it’s greater than the maximum packet size, so that at least one packet can be sent per arbitration round. This effectively utilizes arbitration rounds. Smaller Q leads to larger latency. Higher Q leads to lesser latency but more .burstiness
• Ratioing quantum sizes across requesters: The Q for different requesters can be ratioed to distribute bandwidth in different ratios, just like how it’s done with weights in WRR arbiters. If equal bandwidth distribution is the goal, then the Q should be same for every requester.
• Maximum accumulated credits by a requester: This needs to be bounded value. Popular choices are to bound S = Q = maximum packet size or Q = maximum packet size and S = 2*maximum packet size.
• Grant sequencing: Grant can be issued consecutively or interleaved manner.

Pros

• Ideal for fair scheduling under varying/dynamic data packets traffic.

Cons

• Most logically complex among the arbiters discussed due to the overhead of managing deficit counters, complex corner cases. Hence, it’s not cost effective for simple arbitration applications.

Source codes

The RTL source code of a minimal implementation of these arbiters are available in my GitHub .

Support

Leave a comment or visit support for any queries/feedback regarding the content of this blog.
If you liked Chipmunk , don’t forget to follow!: