Arbitration Overhead

Chapters 14.4–14.5 covered single-path losses (wait states, address overhead); this chapter covers a multi-master loss: arbitration overhead — the cost of getting the bus. The main component is grant latency: the cycles a master waits after requesting the bus before the arbiter grants it — during which the master does no transfers (it doesn't have the bus). The handover itself (switching ownership between masters) is small — the AHB pipeline overlaps most of it (chapter 10.9). Crucially, arbitration overhead is a per-grant cost: it's paid once per bus acquisition, then amortised over the transfers the master does while it holds the bus. So the culprit is frequent re-arbitration — a master that gives up and re-requests the bus often (e.g. after each short burst) re-pays the grant latency every time, making the overhead large relative to the little data moved. The remedies: longer bursts / holding the bus (amortise the grant latency over more data — trading against fairness), or sidestep it entirely with a bus matrix (per-slave arbitration → masters proceed concurrently, no single-bus contention, Module 13). This chapter quantifies the arbitration overhead and how to reduce it.

1. What Is It?

Arbitration overhead is the throughput/latency cost of acquiring the shared bus in a multi-master system. Components:

• Grant latency — the cycles a master waits between requesting (HBUSREQ) and being granted (HGRANT) the bus; it does no transfers meanwhile. The main overhead.
• Handover — the cycles to switch ownership master-to-master; small (the pipeline overlaps most of it, chapter 10.9).
• Per-grant cost — paid once per acquisition, amortised over the transfers done while holding the bus.
• The culprit: re-arbitration — frequent give-up-and-re-request (e.g. per short burst) re-pays the grant latency repeatedly.

So arbitration overhead is the cost of competing for and acquiring the shared bus — primarily the grant latency (waiting for the grant). It's not a per-transfer or per-beat cost (like address overhead or wait states); it's a per-acquisition cost — paid when a master gets the bus, then amortised over everything it does while holding it. So a master that holds the bus for a long burst pays the grant latency once over many beats (negligible overhead), while a master that re-arbitrates per short burst pays it repeatedly (high overhead). So the arbitration overhead's impact depends on the re-arbitration frequency. So it's the per-grant cost of bus acquisition, dominated by grant latency, and made significant by frequent re-arbitration.

2. Why Does It Exist?

Arbitration overhead exists because acquiring a shared bus requires a request-grant handshake (which takes cycles — grant latency), and because that cost is per-acquisition, the frequency of acquisitions (re-arbitration) determines whether it's negligible or significant.

The grant latency from the handshake is the root: in a multi-master system, a master can't just use the shared bus — it must request it (HBUSREQ) and wait for the arbiter to grant it (HGRANT, chapter 10.2). This handshake takes cycles: at minimum, the request must be seen by the arbiter and a grant returned; if other masters hold or want the bus, the wait is longer (the arbiter serves them first). During this wait, the master does no transfers (it doesn't have the bus). So the grant latency is lost time — the overhead of coordinating shared access. So arbitration overhead exists because shared-bus access requires a request-grant handshake that costs cycles. So grant latency is the price of sharing.

The per-acquisition nature is why it's amortisable: the grant latency is paid once — when the master acquires the bus. After acquiring, the master can do many transfers (a long burst) without re-arbitrating (it holds the bus). So the grant latency is amortised over the transfers done while holding the bus — like the address overhead is amortised over a burst's beats (chapter 14.5), but at the bus-acquisition level. So a master that holds the bus for much work pays the grant latency negligibly (once over many transfers); one that holds it briefly pays it significantly. So arbitration overhead is per-acquisition, hence amortisable by holding the bus. So its impact depends on how long a master holds the bus per acquisition.

The reason re-arbitration is the culprit is frequency: if a master frequently gives up and re-acquires the bus — e.g. doing a short burst, releasing, then re-requesting for the next short burst — it re-pays the grant latency every acquisition. So the overhead scales with the number of acquisitions. Frequent re-arbitration (many short acquisitions) → high total overhead; infrequent (few long acquisitions) → low. So the re-arbitration frequency is what makes the per-acquisition cost significant or not. So arbitration overhead exists because: acquiring the shared bus needs a request-grant handshake costing grant latency (the why), the cost is per-acquisition hence amortisable by holding the bus over many transfers (the nature), and frequent re-arbitration (many short acquisitions) re-pays it repeatedly (the culprit). So the overhead is reduced by holding the bus for long bursts (amortise) — trading against fairness (a master holding the bus long starves others, chapter 10.7) — or sidestepped by a bus matrix (per-slave arbitration, no single-bus competition, chapter 13.3). So this chapter quantifies the per-acquisition grant-latency cost, why re-arbitration makes it hurt, and how to reduce or avoid it.

3. Mental Model

Model arbitration overhead as the wait to merge onto a busy highway from an on-ramp — every time you enter the highway, you wait at the ramp for a gap (grant latency); if you drive a long stretch before exiting, that one wait is amortised over a long trip (low overhead per mile); but if you keep exiting and re-entering (re-arbitration), you pay the merge-wait over and over for short stretches — and the fix is either to stay on the highway longer (hold the bus) or to use a road system where each destination has its own lane so you never compete to merge (a bus matrix).

To use a busy highway (the shared bus) from an on-ramp, you must wait at the ramp for a gap to merge (grant latency — waiting for the grant). Once you're on, you drive freely. If you drive a long stretch before exiting (hold the bus for a long burst), that one merge-wait is amortised over a long trip — the wait is a tiny fraction of your travel time (low overhead per mile). But if you keep exiting and re-entering (re-arbitration — give up the bus, re-request) for short stretches, you pay the merge-wait every time — and for short stretches, the waiting dominates the driving (high overhead). The handover of merging itself is quick (you blend into traffic smoothly — the pipeline overlaps it). So the cost is the repeated merge-waits from frequent re-entry. The fixes: stay on the highway longer (hold the bus, long bursts — fewer merges) — but this can block the ramp for others (fairness/starvation); or use a road system where each destination has its own dedicated lane so you never compete to merge (a bus matrix — per-slave arbitration, concurrent access, no single shared highway to merge onto).

This captures arbitration overhead: the highway = the shared bus; waiting at the ramp to merge = grant latency; driving a long stretch = holding the bus for a long burst; amortising the merge-wait over a long trip = amortising grant latency over many transfers; exiting and re-entering repeatedly = frequent re-arbitration; the merge blending in quickly = the small (overlapped) handover; staying on longer but blocking others = holding the bus vs fairness; dedicated lanes per destination = a bus matrix. The repeated merge-waits from frequent re-entry are the overhead — stay on longer or use dedicated lanes.

Watch grant latency before a master's transfers:

The model's lesson: the repeated merge-waits from frequent re-entry are the overhead — stay on longer or use dedicated lanes. In the waveform, the 2-cycle grant latency precedes the transfers; amortise it over a long burst, or avoid the merge entirely with a matrix.

4. Real Hardware Perspective

In hardware, arbitration overhead is the grant latency from the arbiter's request-grant logic (plus contention from other masters), the small overlapped handover, and the re-arbitration frequency set by the masters' burst lengths and the arbitration policy — all absent in a bus matrix's per-slave arbitration.

The grant latency in hardware: the arbiter (chapter 10.x) samples HBUSREQ, applies its policy (priority/round-robin), and drives HGRANT. The minimum grant latency is the arbiter's own logic delay (a cycle or so to register the request and respond). The actual latency is longer when other masters hold or want the bus — the requesting master waits until the arbiter serves it (per the policy). So in hardware, grant latency = the arbiter's response time + the queueing behind other masters. A high-priority master gets a short grant latency (served first); a low-priority one may wait longer (or starve, chapter 10.7). So the grant latency depends on the arbiter policy and the contention.

The small handover (chapter 10.9): switching the bus from master A to master B is mostly overlapped by the pipeline — B's first address phase overlaps A's last data phase, so there's no idle cycle at the handover itself (it's clean and pipelined). So the handover per se adds little overhead — the cost is the grant latency (waiting to be granted), not the handover mechanics. So in hardware, don't confuse the (small) handover with the (larger) grant-latency wait. So the overhead is the wait, not the switch.

The re-arbitration frequency and the matrix: how often a master re-arbitrates depends on its burst length (longer bursts → fewer acquisitions per data moved) and the arbitration scheme (does it hold the bus, or release after each burst?). Frequent re-arbitration (short bursts, release-and-re-request) re-pays the grant latency often. Holding the bus (long bursts) amortises it — but starves other masters (a fairness/latency problem, chapter 10.7). The bus matrix (chapter 13.3) sidesteps this entirely: with per-slave arbitration and concurrent access, a master accessing its own slave doesn't compete for a single bus — so there's no grant latency for accessing an uncontended slave (it just goes). So in hardware, arbitration overhead is the grant-latency wait (arbiter response + contention), amortised by long bursts (vs fairness), and largely eliminated by a bus matrix (concurrent, per-slave — no single-bus competition for uncontended slaves). So the matrix is the structural fix; long bursts the workaround on a shared bus. So in hardware, reduce arbitration overhead by holding the bus longer (shared bus) or moving to a matrix (concurrent).

5. System Architecture Perspective

At the system level, arbitration overhead is a multi-master-specific loss that trades against fairness, and the bus matrix (Module 13) is the architectural answer that removes it for uncontended access — so the overhead's significance depends on whether you're on a shared bus or a matrix.

The multi-master-specific, fairness-traded nature: arbitration overhead exists only in multi-master systems (a single master, AHB-Lite, has no arbitration, chapter 12.3 — zero arbitration overhead). And on a shared bus, reducing it (holding the bus for long bursts) directly trades against fairness: a master holding the bus long starves others (chapter 10.7). So there's a tension: long holds (low arbitration overhead, but poor fairness/latency for others) vs short holds with frequent re-arbitration (good fairness, but high arbitration overhead). So at the system level, on a shared bus, arbitration overhead and fairness are in tension — the arbiter policy (and burst lengths) balances them. So it's a shared-bus design trade.

The matrix removes it for uncontended access: the bus matrix (chapter 13.3) resolves the tension by removing the single-bus competition. With per-slave arbitration and concurrent paths, a master accessing its own (uncontended) slave doesn't arbitrate against other masters — it just goes (no grant latency for that access). Arbitration only occurs when two masters target the same slave (and then only for that slave). So in a matrix, arbitration overhead is largely eliminated for the common case (masters on different slaves) — and fairness is per-slave (each slave's arbiter, no global starvation). So at the system level, the matrix removes the arbitration-overhead-vs-fairness tension for uncontended access. So a matrix is the architectural fix for both arbitration overhead and fairness. So if arbitration overhead (or fairness) is a problem on a shared bus, the answer is often a matrix.

The placing it in the performance model: arbitration overhead is the multi-master term in the performance model (alongside the single-path terms: address overhead, wait states, idle). On a shared bus, it's a real loss (grant latency per acquisition, amplified by re-arbitration). On a matrix, it's near-zero for uncontended access (the matrix's whole point, chapter 13.4). So when analyzing performance, the architect asks: shared bus or matrix? — on a shared bus, account for arbitration overhead (and minimize re-arbitration); on a matrix, it's mostly absent (spread traffic across slaves so masters don't contend, chapter 13.8). So at the system level, arbitration overhead is a multi-master-specific loss that trades against fairness on a shared bus, is removed for uncontended access by a bus matrix (the architectural fix for both overhead and fairness), and is the multi-master term in the performance model (significant on a shared bus, near-zero on a matrix). So understanding it guides the shared-bus-vs-matrix decision and the burst-length/arbitration-policy tuning on a shared bus. So arbitration overhead is where multi-master performance meets the interconnect choice.

6. Engineering Tradeoffs

Arbitration overhead embodies the per-acquisition, fairness-traded, matrix-removable cost.

• Long bursts / hold the bus (amortise) vs fairness. Holding the bus for long bursts amortises the grant latency (low overhead/byte) but starves other masters (poor fairness/latency for them). Short holds with re-arbitration are fairer but pay the overhead repeatedly. The arbiter balances this.
• Shared bus (has overhead) vs bus matrix (removes it). A shared bus has arbitration overhead (grant latency, re-arbitration); a matrix removes it for uncontended access (per-slave arbitration, concurrent). Use a matrix to eliminate the overhead (and the fairness tension) — at the matrix's hardware cost.
• Grant latency vs handover. The grant latency (waiting to be granted) is the real overhead; the handover (switching ownership) is small (pipeline-overlapped). Don't conflate them; reduce the grant-latency wait (fewer acquisitions, higher priority, or a matrix).
• Arbitration policy: priority (low latency for critical) vs round-robin (fair). A high-priority master gets low grant latency (low overhead) at others' expense; round-robin spreads grant latency fairly. Tune per the critical master's needs (chapter 10.5-10.6).

The throughline: arbitration overhead is the cost of acquiring the shared bus — mainly grant latency (cycles waiting between request and grant); the handover is small (pipeline-overlapped). It's a per-acquisition cost, amortised over the transfers done while holding the bus — so frequent re-arbitration (give-up-and-re-request per short burst) is the culprit (re-paying grant latency). Reduce it with longer bursts / holding the bus (trading against fairness), or sidestep it with a bus matrix (per-slave arbitration → concurrent, no single-bus competition for uncontended slaves). It's the multi-master term in the performance model — significant on a shared bus, near-zero on a matrix.

7. Industry Example

Analyze arbitration overhead for a DMA on a shared bus vs a matrix.

A CPU and a DMA share a bus; the DMA streams data. Compare shared-bus arbitration patterns and a matrix.

• Shared bus, frequent re-arbitration (high overhead). Suppose the DMA does short (INCR4) bursts, releasing the bus between them (to be fair to the CPU). Each acquisition pays, say, a 2-cycle grant latency. So per INCR4 burst (4 beats + ~2 grant + 1 address): the grant latency is a notable fraction of the ~7 cycles — significant overhead. Over many short bursts, the repeated grant latencies erode the DMA's throughput.
• Shared bus, hold the bus (low overhead, fairness cost). If the DMA instead does long (INCR16) bursts, holding the bus, it pays the grant latency once per 16 beats — negligible overhead. But holding the bus for 16 beats delays the CPU (it waits for the DMA to finish) — a fairness/latency cost for the CPU. So the arbiter must balance: long enough bursts to amortise arbitration overhead, short enough to not starve the CPU. (A max-burst limit, or priority for the CPU, tunes this.)
• The tension. On the shared bus, low arbitration overhead (long DMA holds) and good CPU fairness (short DMA holds) are in tension. The arbiter policy + burst lengths balance them — a classic shared-bus trade.
• Bus matrix (removes the tension). Move to a bus matrix: the DMA accesses its memory (e.g. a dedicated buffer SRAM) and the CPU accesses its memory (flash/data SRAM) — different slaves, concurrent paths. Now the DMA doesn't arbitrate against the CPU (different slaves) — no grant latency for the DMA's accesses, and the CPU isn't delayed by the DMA. The arbitration overhead is removed for the uncontended (different-slave) case, and fairness is moot (they don't compete). The matrix resolves both.
• Result. On the shared bus, the DMA's arbitration overhead trades against CPU fairness (tuned by burst length/policy). On the matrix, both vanish for different-slave access — the DMA streams its memory at full rate while the CPU runs unimpeded. The matrix is the structural fix.

The example shows arbitration overhead as a shared-bus, per-acquisition cost (significant with frequent re-arbitration, amortised by holding the bus, traded against fairness) — and the bus matrix as the architectural fix that removes it for uncontended access. This is how arbitration overhead is analyzed and addressed.

8. Common Mistakes

9. Interview Insight

Arbitration overhead is a multi-master interview topic — the per-acquisition/grant-latency nature, the re-arbitration culprit, and the matrix-removes-it point are the signals.

The answer that lands gives the per-acquisition nature and the matrix fix: "Arbitration overhead is the cost of acquiring the shared bus in a multi-master system. The main component is grant latency — the cycles a master waits between requesting the bus and being granted it, during which it does no transfers. The handover itself, switching ownership between masters, is small because the AHB pipeline overlaps most of it. The key point is that arbitration overhead is a per-acquisition cost, not per-transfer or per-beat — it's paid once each time a master gets the bus, then amortised over all the transfers the master does while it holds the bus. So the culprit is frequent re-arbitration: a master that does a short burst, releases the bus, and re-requests for the next short burst re-pays the grant latency every time, so the overhead can dominate the little data moved. You reduce it by doing more per acquisition — longer bursts, or holding the bus across transfers — which amortises the grant latency, but that trades against fairness, because holding the bus long starves other masters. The structural fix is a bus matrix: with per-slave arbitration and concurrent paths, a master accessing its own uncontended slave doesn't arbitrate against other masters at all — no grant latency — and arbitration only happens when two masters target the same slave. So the matrix removes the arbitration overhead for the common case and also resolves the fairness tension. And note a single-master system, AHB-Lite, has no arbitration overhead at all." The per-acquisition/grant-latency nature, the re-arbitration culprit, and the matrix-removes-it point are the senior signals.

10. Practice Challenge

Reason from arbitration overhead.

1. The components. Identify the main arbitration overhead (grant latency) and why the handover is small.
2. Per-acquisition. Explain why arbitration overhead is per-acquisition and how re-arbitration makes it significant.
3. Read the waveform. From Figure 2, identify the grant latency and where transfers begin.
4. Fairness trade. Explain the tension between holding the bus (low overhead) and fairness.
5. Matrix fix. Explain how a bus matrix removes arbitration overhead for uncontended access.

11. Key Takeaways

• Arbitration overhead is the cost of acquiring the shared bus — mainly grant latency (cycles waiting between request and grant); the handover (switching ownership) is small (pipeline-overlapped).
• It's a per-ACQUISITION cost (not per-transfer/beat) — paid once when a master gets the bus, amortised over the transfers done while holding it.
• Frequent re-arbitration is the culprit — give-up-and-re-request per short burst re-pays the grant latency repeatedly, making the overhead dominate the little data moved.
• Reduce it by doing more per acquisition — longer bursts / holding the bus (amortise the grant latency) — trading against fairness (holding the bus starves others).
• A bus matrix removes it for uncontended access — per-slave arbitration + concurrent paths mean a master on its own slave doesn't acquire a shared bus (zero grant latency); arbitration only for same-slave contention. The structural fix for both overhead and fairness.
• It's the multi-master term in the performance model — significant on a shared bus, zero in single-master (AHB-Lite), near-zero on a matrix for spread traffic. Diagnose by granularity (per-acquisition) and fix the acquisition frequency.

12. What Comes Next

You now understand arbitration overhead — the per-acquisition grant-latency cost, amortised by holding the bus, removed by a matrix. With the wait-state penalty, burst efficiency, and this, you have the major efficiency losses. The final chapters synthesize:

• Bridge Penalty (next) — the latency added by the AHB-to-APB bridge.
• Bottleneck Analysis — locating the slowest slave in an AHB path.
• Performance Debug — a method to measure and improve AHB performance (synthesizing all the effects).

To revisit the arbitration this builds on, see Arbitration Timing and Starvation; for the matrix that removes the overhead, see The Bus Matrix Concept.