AMBA AXI · Module 12

Arbiter & Arbitration

How an AXI interconnect resolves contention at a shared subordinate — round-robin, fixed-priority, and QoS-weighted arbitration schemes, the fairness-vs-priority trade-off, the arbiter state machine, and starvation avoidance.

When multiple managers target the same subordinate (the per-subordinate contention of Chapter 12.2), the interconnect must decide who goes first — that's the arbiter's job. The arbitration scheme determines the system's fairness (does any manager starve?), throughput (is the port kept busy?), and priority (do latency-critical masters get precedence?). This chapter covers the main schemes — round-robin, fixed-priority, and QoS-weighted — the fairness-vs-priority trade-off, the arbiter as a state machine, and how to avoid starvation.

1. The Arbiter's Job

At each shared subordinate port, an arbiter sees the set of managers currently requesting access and grants one per cycle (or per transaction). The granted manager's transaction proceeds; the others wait and are reconsidered next round. Arbitration happens on the address channels (AW and AR contention are arbitrated, each independently — read and write are separate), and similarly on response paths where they contend.

A good arbiter has three properties: no starvation (every requester eventually wins), high throughput (the port isn't idle while requests are pending — grant someone every cycle there's a request), and policy (it can favor higher-priority/QoS masters when desired). The scheme chosen trades these off.

Figure 1 — the arbiter at a shared subordinate port. Multiple managers request the same subordinate; the arbiter grants one per round, the others wait and are reconsidered. Arbitration is per-channel (AW and AR independently). A good arbiter is starvation-free, keeps the port busy, and can honor priority/QoS.

2. The Arbitration Schemes

The common schemes:

Round-robin (RR): rotate priority among requesters so each gets a fair turn — after granting a manager, it goes to the back of the line. No starvation, fair bandwidth distribution. The common default for general traffic.
Fixed-priority: managers have static priorities; the highest-priority requesting manager always wins. Simple and low-latency for the top priority, but lower-priority masters can starve if a high-priority one is always requesting.
QoS-weighted: use AxQOS (Chapter 6.5) to weight arbitration — higher-QoS transactions get more grants/precedence. Programmable priority that lets software/system tune which masters get bandwidth under contention.
Weighted round-robin / least-recently-granted: hybrids that give some masters proportionally more turns while still bounding everyone's wait — balancing fairness and priority.

The choice depends on the traffic: RR for fairness among equals, fixed-priority where one master is genuinely most critical (and starvation of others is acceptable or impossible), QoS-weighted for tunable, mixed-criticality systems.

Figure 2 — arbitration schemes. Round-robin: rotate turns, fair, no starvation (default). Fixed-priority: highest-priority requester always wins — simple, low-latency for top priority, but can starve the rest. QoS-weighted: AxQOS weights grants — programmable, tunable bandwidth. Weighted-RR/LRG hybrids balance proportional priority with bounded waits.

3. The Arbiter State Machine

Conceptually, an arbiter cycles through request → grant → advance:

Figure 3 — a round-robin arbiter state machine. From Idle (no requests), when request(s) arrive it grants the highest-priority requester in the current rotation (Grant); when the transfer is accepted it advances the rotation pointer past the winner (Rotate); then it grants the next pending requester, or returns to Idle if none. The rotating pointer is what makes it fair (no starvation).

The rotating pointer is what gives round-robin its fairness: after a manager wins, the pointer moves past it, so it won't win again until everyone ahead of it in the rotation has had a turn — bounding each manager's worst-case wait. Fixed-priority lacks this (the pointer never moves off the top priority), which is why it can starve. The arbiter also typically grants per address transaction (once granted, the manager's burst proceeds on the granted path), then re-arbitrates for the next.

4. Fairness vs Priority — The Core Trade

Arbitration is fundamentally a fairness-vs-priority trade-off:

Fairness (round-robin) treats requesters equally — no one starves, bandwidth is shared evenly. Best when masters are peers and predictable latency for all matters.
Priority (fixed-priority) favors the most critical master — lowest latency for it — at the cost of potentially starving others. Best when one master genuinely must come first (e.g., a real-time display controller that must never underflow) and starving others is acceptable.
QoS-weighted is the tunable middle: it lets the system grant proportionally more bandwidth to higher-QoS masters without fully starving lower ones — combining priority's responsiveness with fairness's safety, programmable per workload.

Real interconnects often use QoS-weighted or weighted round-robin precisely because pure fairness ignores criticality and pure priority risks starvation. The arbitration policy is a key performance knob: it determines, under contention, which master gets the bandwidth and which waits — directly shaping system latency and throughput.

Figure 4 — the fairness-vs-priority trade. Round-robin maximizes fairness (no starvation, equal shares) but ignores criticality. Fixed-priority maximizes responsiveness for the top master but can starve others. QoS-weighted (and weighted-RR) is the tunable middle — proportional priority with bounded waits. The policy is a performance knob set to the traffic's criticality mix.

5. Common Misconceptions

Myths to unlearn

"Arbitration is global." It's per-subordinate (per shared port) and per-channel (AW/AR independently) in a crossbar — not one global arbiter. Distinct subordinates don't arbitrate against each other.
"Fixed-priority is always best for important masters." It gives the top master lowest latency but can starve lower ones. Use it only where starvation is acceptable or impossible; otherwise QoS-weighted/RR.
"Round-robin can't express priority." Plain RR is equal-share, but weighted RR and QoS-weighting add priority while keeping bounded waits. RR is the fair baseline you extend.
"AxQOS guarantees a master gets the bus." AxQOS is an advisory weight the arbiter may use (Chapter 6.5) — it influences arbitration, doesn't guarantee or order completion.
"The arbiter holds the grant for the whole burst forever." It grants per address transaction; once granted the burst proceeds, then it re-arbitrates. It doesn't lock the port indefinitely (that was the removed AXI3 locked mode, 9.4).
"Arbitration only affects latency, not correctness." Mostly true for performance, but a starving master can cause functional failures (a real-time master missing deadlines), so fairness has correctness implications.

6. Debugging Insight

🔍 Debugging insight — starvation, unfairness, and priority-inversion

Arbitration bugs are performance/fairness problems at shared ports:

A manager never gets the bus (starvation)? Fixed-priority with a higher-priority master always requesting, starving this one. Switch to round-robin or QoS-weighted, or ensure the high-priority master yields. Check the arbitration scheme at that subordinate.
Bandwidth shared unfairly / one master dominates? The scheme isn't fair for the workload — a fixed-priority or mis-weighted arbiter. Use RR or rebalance the QoS weights.
A high-QoS master not getting precedence? The arbiter isn't honoring AxQOS, or QoS values are mis-assigned (all the same, or the master drives QoS=0). Check the arbiter's QoS support and the master's AxQOS (Chapter 6.5).
Real-time master missing deadlines under load? A priority-inversion-like situation — a critical master waiting behind bulk traffic because arbitration doesn't prioritize it. Raise its QoS or use a scheme that favors it.
Throughput drops with idle cycles despite pending requests? The arbiter isn't work-conserving — it's leaving the port idle while requests wait (a bug). It should grant someone every cycle there's a request.

The triage: starved → fixed-priority/scheme; unfair → wrong scheme/weights; QoS ignored → arbiter QoS support or master QoS values; deadline miss → priority too low; idle-with-requests → non-work-conserving arbiter. All point at the arbitration policy at the contended port.

7. Verification Insight

✅ Verification insight — fairness, no-starvation, throughput, and QoS

Arbitration verification is mostly performance/fairness checking under contention, plus correctness that no transaction is lost. No starvation: drive sustained contention from all managers and assert every requester is eventually granted within a bounded time (the key fairness property — especially for round-robin/weighted schemes). Fairness/weighting: under equal requests, RR grants equal shares; under QoS weighting, higher-QoS masters get proportionally more — measure the grant distribution against the expected policy. Throughput: the arbiter is work-conserving (no idle cycles while requests pend) and reaches full port utilization under load. Correctness: every arbitrated transaction completes correctly (no loss/misrouting through the arbiter), and AXI ordering is preserved.

Coverage should include: single requester (trivial grant), all managers contending continuously (fairness/starvation), bursty/intermittent requests, mixed QoS values (weighting), and the priority extremes (one master always high-priority — does the policy starve or bound the others?). The highest-value tests are the sustained all-master contention (proves no starvation and measures fairness) and the QoS-weighting distribution (proves the policy actually shapes bandwidth as intended). Since arbitration determines who gets bandwidth under load, verifying the fairness/weighting behavior — not just that transactions complete — is the essential check; a correct-but-unfair arbiter passes functional tests while starving a master in the real system.

8. Interview Questions

9. Summary

The arbiter resolves contention at a shared subordinate port (per-subordinate, per-channel), granting one of the competing managers per round. The main schemes: round-robin (rotate turns — fair, no starvation, the default for peers), fixed-priority (top requester always wins — simple and low-latency for it, but can starve others), QoS-weighted (use AxQOS to weight grants — programmable, proportional priority without full starvation), and weighted-RR/LRG hybrids. The rotating pointer is what makes round-robin starvation-free; fixed-priority's static pointer is why it can starve. A good arbiter is starvation-free, work-conserving (no idle cycles with pending requests), and policy-honoring.

The core trade-off is fairness vs priority: round-robin maximizes fairness, fixed-priority maximizes responsiveness for one master (risking starvation), and QoS-weighting is the tunable middle for mixed-criticality systems — which is why real interconnects favor QoS-weighted/weighted-RR. Arbitration is a key performance knob, and its bugs (starvation, unfairness, ignored QoS, priority inversion, non-work-conserving) are performance/fairness failures that functional tests miss — so verify the fairness/weighting behavior (bounded waits, grant distribution, utilization) under sustained contention, not just transaction correctness. Next: mux/demux and ID-based routing — how responses find their way back through the interconnect.

10. What Comes Next

You've got contention resolution; next, routing responses back:

12.5 — Mux/Demux & ID-Based Routing (coming next) — how the interconnect muxes/demuxes channels and routes responses home by ID, including ID-width remapping.

Previous: 12.3 — Decoder & Address Map. Related: 6.5 — AxPROT, AxQOS & AxREGION for the QoS signal, and 12.2 — Crossbar Architecture for the per-subordinate contention this resolves. For the broader protocol catalog, see the AMBA family overview doc.