Fixed-Priority Arbitration

Chapters 10.1–10.4 covered the arbitration mechanism (request/grant, HMASTER, locking). This chapter covers the first arbitration policy — fixed-priority. Each master is assigned a fixed priority level, and when several masters request the bus at once, the arbiter always grants the highest-priority requester. So a high-priority master gets the bus whenever it wants it, and lower-priority masters get it only when no higher-priority master is requesting. The trade-off: fixed-priority gives very low latency for high-priority masters (good for latency-critical traffic) and is simple and deterministic, but it risks starving low-priority masters — a continuously-requesting high-priority master can monopolize the bus, leaving lower ones waiting indefinitely. So fixed-priority suits systems with a clear priority ordering and bounded high-priority demand. It's the simplest policy, and the natural choice when some masters genuinely matter more than others.

1. What Is It?

Fixed-priority arbitration assigns each master a fixed priority level. When multiple masters request the bus simultaneously, the arbiter grants the highest-priority requester.

So the rule is simple: highest priority wins. If masters A (priority 1), B (priority 2), and C (priority 3) all request, A wins. If only B and C request, B wins. If only C requests, C wins. So a master gets the bus when it's the highest-priority requester at that moment. A high-priority master (A) is granted whenever it requests (nothing outranks it), giving it the bus on demand. A low-priority master (C) is granted only when no higher-priority master is requesting — so it waits whenever A or B wants the bus. The priorities are fixed (assigned at design time, not changing) — hence "fixed-priority." It's the simplest policy: a static ranking, highest requester wins.

2. Why Does It Exist?

Fixed-priority exists because in many systems, some masters genuinely matter more than others — they have stricter latency requirements — and a fixed priority ordering is the simplest way to ensure those masters get the bus first.

Consider a system where one master is latency-critical — say a real-time controller, or a master servicing a deadline-sensitive task — while others are less urgent (a background DMA). The critical master should get the bus immediately when it needs it, even if others are waiting. Fixed-priority expresses this directly: give the critical master the highest priority, and it'll always win. So fixed-priority exists to serve systems with a clear hierarchy of master importance — it ensures the most important master gets the bus first. This is the natural policy when masters have genuinely different urgencies: rank them, and the most urgent wins.

The reason fixed-priority is simple is that it's a static comparison: the arbiter just compares the requesters' (fixed) priorities and grants the highest. There's no state to track (no history, no rotation) — it's a combinational priority-encoder. So fixed-priority is trivial to implement: a priority encoder on the requests. This simplicity is a real advantage — minimal arbiter logic, fast, deterministic. So fixed-priority exists partly because it's the simplest possible policy: a static priority comparison, no state. For systems that just need "the important master goes first," this simplicity is ideal.

The reason it gives very low latency to high-priority masters is that the highest-priority master never waits for a lower one — it always wins contention. So a high-priority master's bus-access latency is minimal (it only waits if an even higher master is requesting, and the top master never waits at all). So fixed-priority exists to provide guaranteed low latency for the top masters — exactly what latency-critical masters need. This is its key strength: bounded, low latency for high-priority traffic. The cost (the reason it's not always used) is the flip side: low-priority masters can be starved (chapter 10.7) — they wait whenever a higher master requests, potentially forever if a high master is always busy. So fixed-priority exists for its low-priority-master-latency strength, accepting the starvation risk — a trade that suits systems with a clear priority order and bounded high-priority demand. (Round-robin, chapter 10.6, trades this for fairness.)

3. Mental Model

Model fixed-priority as a hospital triage where the most critical patient is always seen first — the ER doctor (arbiter) always takes the highest-acuity patient waiting, so critical cases get immediate care, but a minor case might wait a very long time if critical cases keep arriving.

In a hospital ER (the bus), patients (masters) arrive needing the doctor (the bus). Triage assigns each an acuity (priority): critical, urgent, minor. The doctor (arbiter) always sees the highest-acuity patient waiting (highest-priority requester). So a critical patient is seen immediately (highest priority — minimal wait), which is exactly right for a life-threatening case (latency-critical master). But a minor case (low-priority master) is seen only when no higher-acuity patient is waiting — and if critical/urgent patients keep arriving, the minor case waits a very long time, potentially the whole shift (starvation). The triage is simple (just compare acuity) and ensures the critical patients are served first, but it's unfair to minor cases when the ER is busy with critical ones.

This captures fixed-priority: acuity levels = fixed priorities; the doctor always taking the highest-acuity patient = the arbiter granting the highest-priority requester; critical patients seen immediately = high-priority masters' low latency; minor cases waiting a long time when critical cases keep arriving = low-priority starvation; simple triage = the simple priority comparison. Most critical first, simple, but unfair to minor cases.

Watch fixed-priority granting the highest-priority requester:

The model's lesson: highest-priority requester always wins — the top master has the bus on demand, low ones wait. In the waveform, A (priority 1) wins over C (priority 3) whenever A requests; C gets the bus only when A stops. If A requested forever, C would be starved. Fixed-priority serves the top master immediately, at the low master's expense.

4. Real Hardware Perspective

In hardware, fixed-priority arbitration is a priority encoder on the masters' HBUSREQ signals — combinational logic that grants the highest-priority asserted request — making it the simplest, smallest, fastest arbiter.

The priority encoder takes the HBUSREQ signals (one per master) and outputs the grant to the highest-priority asserted one. Since the priorities are fixed (a static ranking), this is pure combinational logic: a priority encoder that, given the set of requests, selects the highest-priority. No state, no memory, no sequential logic. So the fixed-priority arbiter is just a priority encoder on the requests — minimal hardware. This is the simplest possible arbiter implementation, which is a real advantage: small area, low latency (combinational, no clocked state), easy to verify.

The fixed priorities are wired at design time: master A is priority 1, B is 2, etc. — the ranking is baked into the priority encoder's structure (which request it favors). So changing the priorities means changing the hardware (or a configurable encoder). The ranking is static — it doesn't adapt to history or load. So in hardware, the priority order is a design-time decision, fixed in the encoder. This is why it's "fixed"-priority: the ranking is fixed in the hardware.

The determinism is a hardware property worth noting: because fixed-priority is a static priority comparison, the grant is deterministic — given a set of requests, the grant is always the same (the highest-priority requester). So the arbitration behavior is fully predictable, which simplifies verification and timing analysis (the highest-priority master's latency is bounded and known). So fixed-priority's hardware is not only simple but deterministic — a benefit for systems that need predictable arbitration. (Round-robin, chapter 10.6, has state and is less trivially deterministic.)

A hardware note on combining with the grant timing: the priority encoder produces the grant, but the actual bus handover still follows the grant-then-own timing (chapter 10.2) — the granted master takes the bus at the clean boundary (HGRANT + HREADY high). So fixed-priority decides who is granted (the priority encoder); the when of taking the bus is the standard handover timing. And a locked transfer (chapter 10.4) overrides the priority decision while HLOCK is asserted (the locking master keeps the grant regardless of priorities). So fixed-priority is the who policy, composed with the handover timing and lock handling. In hardware, the priority encoder feeds the grant logic, which respects locks and the handover timing.

5. System Architecture Perspective

At the system level, fixed-priority is the right policy when masters have a clear hierarchy of urgency and the high-priority masters' demand is bounded — but it requires care to avoid starving low-priority masters.

The clear-hierarchy fit is fixed-priority's sweet spot: systems where some masters are genuinely more latency-critical than others — a real-time control master that must respond quickly, a processor that should preempt background DMA. Fixed-priority directly serves this: rank the masters by urgency, and the critical ones always win. So fixed-priority suits systems with a natural priority ordering — where it's clear which masters matter most. This is common: many systems do have a clear hierarchy (e.g., CPU > DMA > background). So fixed-priority is a natural, common choice when the priority order is clear.

The bounded-demand requirement is the key caveat: fixed-priority works well only if the high-priority masters' demand is bounded — i.e., they don't request the bus continuously, leaving gaps for lower masters. If a high-priority master requests the bus all the time, lower masters are starved (never granted, chapter 10.7). So fixed-priority is safe only when the high-priority traffic is intermittent (bursts of activity, then idle), leaving the bus available for lower masters between. So the architect must ensure the high-priority demand is bounded — or low masters will starve. This is the central system consideration with fixed-priority: it's low-latency for the top but starves the bottom if the top is always busy.

The starvation mitigation (chapter 10.7) shapes the system design: to prevent starvation under fixed-priority, the system must either ensure bounded high-priority demand, or use a hybrid policy (e.g., fixed-priority with a fairness mechanism, or round-robin for equal-priority masters). So pure fixed-priority is used when starvation is acceptable (the low masters can tolerate waiting, or the high demand is bounded); otherwise a fairer policy (round-robin, chapter 10.6) or a hybrid is used. So at the system level, fixed-priority is chosen when the priority hierarchy is clear and starvation is manageable (bounded high demand or tolerant low masters). When fairness matters (no starvation), round-robin or a hybrid is preferred. So fixed-priority's system role is serving clear-hierarchy, bounded-demand systems with low high-priority latency — a common and simple choice, used with awareness of the starvation risk. The policy choice (fixed-priority vs round-robin vs hybrid) is a key arbitration design decision driven by the masters' latency needs and the fairness requirement.

6. Engineering Tradeoffs

Fixed-priority embodies the simple-priority-ranking design.

• Fixed-priority (low latency for top) vs round-robin (fair). Fixed-priority gives the highest-priority master minimal latency (always wins) but starves low masters; round-robin (chapter 10.6) is fair (no starvation) but doesn't prioritize. Fixed-priority for clear hierarchy, round-robin for fairness.
• Simple/stateless vs stateful policies. Fixed-priority is a stateless priority encoder — simplest, smallest, fastest, deterministic. Stateful policies (round-robin, weighted) are fairer but more complex. Fixed-priority wins on simplicity.
• Static priority vs dynamic. Fixed (static) priorities are simple and deterministic but can't adapt to load. Dynamic-priority schemes adapt but are complex. AHB systems often use fixed (static) for its simplicity, accepting it doesn't adapt.
• Low-latency top vs starvation risk. The benefit (low latency for high-priority) and cost (starvation for low-priority) are two sides of the same coin. The policy is right when the top's low latency matters and the bottom's starvation is manageable (bounded high demand).

The throughline: fixed-priority arbitration assigns each master a fixed priority and always grants the highest-priority requester — a simple, stateless, deterministic priority encoder. It gives high-priority masters very low latency (they always win) at the cost of possible starvation for low-priority masters (a continuously-requesting high master monopolizes the bus). It suits systems with a clear priority hierarchy and bounded high-priority demand. The policy choice between fixed-priority and round-robin (chapter 10.6) — or a hybrid — is driven by the masters' latency needs versus the fairness requirement.

7. Industry Example

Trace fixed-priority arbitration in a system with a clear hierarchy.

A system has a CPU (high priority), a display controller (medium), and a background DMA (low).

• The priority ordering. The CPU is latency-critical (it must respond quickly to execute code and handle events), so it's highest priority. The display controller needs steady bandwidth (medium). The background DMA (e.g., copying data not on a deadline) is least urgent, lowest priority. So the hierarchy is clear: CPU > display > DMA.
• The CPU gets the bus on demand. Whenever the CPU requests the bus, it wins (highest priority) — minimal latency, even if the display and DMA are waiting. So the CPU's bus access is fast, which is what its latency-critical execution needs. Fixed-priority serves the CPU's urgency directly.
• The display gets the bus when the CPU isn't using it. The display controller is granted when the CPU isn't requesting — getting the bus in the gaps of the CPU's activity. As long as the CPU's demand is bounded (it doesn't use the bus 100% of the time), the display gets enough bandwidth.
• The DMA gets the leftover bus. The background DMA gets the bus only when neither the CPU nor the display is requesting — the leftover bandwidth. Since it's not on a deadline, this is acceptable: it makes progress when the bus is otherwise idle.
• The bounded-demand assumption. This works because the CPU's and display's demand is bounded — they don't saturate the bus, leaving time for the DMA. If the CPU (or display) requested the bus continuously, the DMA would be starved (never making progress). So the system relies on the high-priority masters' bounded demand to avoid starving the DMA. The architect verified this (the CPU/display don't saturate the bus).
• If starvation were a risk. If the high-priority demand could be continuous (risking DMA starvation), the system would use a different policy — e.g., round-robin (chapter 10.6) for fairness, or a hybrid that guarantees the DMA some minimum bandwidth. But with bounded high demand, fixed-priority's simplicity and low CPU latency make it the right choice here.

The example shows fixed-priority serving a clear hierarchy: the CPU (high priority) gets the bus on demand (low latency), the display (medium) gets the gaps, and the DMA (low) gets the leftover — working because the high-priority demand is bounded (leaving time for the DMA). The simplicity and low high-priority latency suit this clear-hierarchy system, with the starvation risk managed by the bounded demand.

8. Common Mistakes

9. Interview Insight

Fixed-priority is a common interview topic — the highest-wins rule, the low-latency-for-top benefit, and the starvation risk are the signals.

The answer that lands gives the rule and the trade-off: "In fixed-priority arbitration, each master has a fixed priority level, and the arbiter always grants the highest-priority master that's requesting. So a high-priority master gets the bus whenever it wants it — nothing outranks it, so its latency is minimal — while a low-priority master gets the bus only when no higher-priority master is requesting. The benefits are that it gives high-priority masters very low, bounded latency, which is good for latency-critical traffic, and it's the simplest policy — just a combinational priority encoder on the requests, stateless and deterministic. The big downside is starvation: if a high-priority master requests the bus continuously, the lower-priority masters never get granted — they're starved indefinitely. So fixed-priority is unfair, and it's safe only when the high-priority masters' demand is bounded — they don't saturate the bus, leaving gaps for the lower masters. It suits systems with a clear priority hierarchy and bounded high-priority demand. When fairness matters — no starvation — you'd use round-robin or a hybrid instead." The highest-wins rule, the low-latency benefit, the starvation con, and the bounded-demand requirement are the senior signals.

10. Practice Challenge

Reason from fixed-priority arbitration.

1. State the rule. Explain how fixed-priority decides who gets the bus.
2. Read the waveform. From Figure 2, explain why C is starved while A requests.
3. The trade-off. Give the benefit and the cost of fixed-priority.
4. The condition. State the condition under which fixed-priority is safe (avoids starvation).
5. When to choose it. Describe a system where fixed-priority is appropriate and one where it isn't.

11. Key Takeaways

• Fixed-priority arbitration: each master has a fixed priority, and the arbiter always grants the highest-priority requester.
• A high-priority master gets the bus on demand (whenever it requests — minimal latency); a low-priority master gets it only when no higher master is requesting.
• Benefits: very low, bounded latency for high-priority masters; simplest policy (a stateless combinational priority encoder); deterministic.
• Cost: starvation — a continuously-requesting high-priority master monopolizes the bus, starving low-priority masters indefinitely. Fixed-priority is unfair.
• It's safe only with bounded high-priority demand — the high masters must leave gaps for the lower ones, or the low masters starve.
• Suits clear-hierarchy, bounded-demand systems; when fairness matters (no starvation), round-robin (chapter 10.6) or a hybrid is preferred. The policy choice is driven by latency needs vs fairness.

12. What Comes Next

You now understand fixed-priority arbitration. The next chapter covers the fair alternative:

• 10.6 — Round-Robin Arbitration (coming next) — round-robin scheduling (fair, no starvation) and when it's preferred over fixed-priority.
• 10.7 — Starvation (coming soon) — master starvation and how arbitration policy avoids it.

To revisit the arbitration mechanism, see HBUSREQ & HGRANT and Why Arbitration Exists. For locked transfers that override priority, see Locked Transfers (HLOCK). For the broader protocol map, see the AMBA family overview.