Skip to content

AMBA AHB · Module 7

SPLIT Response

The legacy full-AHB SPLIT response — how it improves on RETRY by having the subordinate remember the master (HMASTER) and notify the arbiter when ready (HSPLIT), eliminating polling at the cost of significant complexity.

Chapter 7.3 covered RETRY — free the bus, but the master polls (re-issues blindly until ready). This chapter covers SPLIT, RETRY's more sophisticated sibling, which solves the polling problem. With SPLIT, the subordinate remembers which master made the transfer (using HMASTER) and, when it is finally ready, notifies the arbiter (via the HSPLIT bus) so the master is re-granted exactly when the data is available — no blind polling. The cost is significant complexity: a split-aware arbiter, the HSPLIT signal, and per-master tracking in the subordinate. Like RETRY, SPLIT is full-AHB only (dropped in AHB-Lite/AHB5), and its complexity — not just RETRY's inefficiency — is a major reason the industry moved to simpler buses and AXI.

1. What Is It?

SPLIT is a full-AHB response (a two-cycle response, like ERROR and RETRY) that frees the bus for a slow subordinate and arranges for the master to be re-granted only when the subordinate is ready — eliminating RETRY's polling.

The SPLIT flow adds notification to RETRY's cancel-and-free:

  1. The master issues a transfer; the slow subordinate sees which master it is via HMASTER, and records it.
  2. The subordinate returns SPLIT: the transfer is cancelled, the bus freed — but the subordinate remembers the master (unlike RETRY).
  3. The arbiter masks that master — it is not granted while the subordinate is busy, so the master does not poll.
  4. When the subordinate is ready, it asserts that master's bit on HSPLIT (a bus with one bit per master) — the "call back."
  5. The arbiter un-masks and re-grants the master, which re-issues and completes OKAY.
A five-step SPLIT flow showing HMASTER recording the master, SPLIT freeing the bus, the arbiter masking the master, HSPLIT notifying readiness, and re-grant to completion.
Figure 1 — the SPLIT mechanism. The subordinate records which master issued the transfer (via HMASTER), returns SPLIT (cancel, free the bus), and the arbiter masks that master so it doesn't poll. When ready, the subordinate asserts the master's bit on HSPLIT; the arbiter un-masks and re-grants the master, which re-issues and completes OKAY. HMASTER + HSPLIT let the subordinate call the master back when ready — eliminating RETRY's blind polling.

The essence of SPLIT is notification instead of polling: where RETRY's master keeps re-issuing blindly, SPLIT's master is parked (masked by the arbiter, doing nothing) until the subordinate calls it back (via HSPLIT). So the master wastes no attempts — it is re-granted precisely when the data is ready. This is strictly more efficient than RETRY's polling, but it requires the extra machinery: HMASTER (so the subordinate knows whom to call back), HSPLIT (the callback signal), and a split-aware arbiter (to mask and un-mask masters).

2. Why Does It Exist?

SPLIT exists to fix RETRY's central inefficiency — the wasted polling — by adding the one thing RETRY lacks: a way for the subordinate to tell the master (via the arbiter) when it's ready.

RETRY's flaw (chapter 7.3) is that the subordinate forgets the transfer, so the master must re-issue blindly, wasting attempts. The fix is conceptually simple: have the subordinate remember the master and notify when ready, so the master is re-granted only at the right moment. SPLIT implements exactly that. The subordinate records the master (HMASTER), and signals readiness (HSPLIT) to the arbiter, which re-grants the master. So SPLIT exists because RETRY's polling is wasteful and the obvious cure is notification — SPLIT is RETRY done efficiently. Its entire reason for being is removing the wasted retries.

The reason SPLIT needs HMASTER is that the subordinate must know which master to call back — and on a multi-master bus, several masters could be issuing transfers. HMASTER is the signal (driven by the arbiter) that tells the subordinate the ID of the master currently making the transfer. So the subordinate records HMASTER on a SPLIT, and later uses it to assert the right bit on HSPLIT. Without HMASTER, the subordinate couldn't identify whom to notify. So HMASTER exists (in part) to make SPLIT possible — it is the master-identity that the callback needs.

The reason SPLIT needs a split-aware arbiter is that someone must park the split master (not grant it while it waits) and un-park it on the HSPLIT notification. The arbiter is the component that grants the bus, so it is the natural place to mask the split master and re-grant it when HSPLIT fires. So SPLIT requires arbiter cooperation — the arbiter must understand SPLIT, track which masters are split (masked), and respond to HSPLIT. This is a significant added complexity in the arbiter, and it is why SPLIT is much more involved than RETRY. SPLIT exists as an efficiency improvement, but it pays for it with this arbiter and signaling complexity — a trade that, in hindsight, the industry judged not worth it (favoring AHB-Lite's simplicity and AXI's native concurrency).

3. Mental Model

Model SPLIT as a restaurant that takes your number and texts you when your table is ready — you leave (free the bus), do other things, and come back only when called, instead of repeatedly asking "is it ready yet?"

At a busy restaurant (the bus), you ask for a table (issue a transfer). It's not ready, but instead of saying "come back and ask again" (RETRY's polling), the host takes your name and number (HMASTER — remembers who you are) and says "we'll text you" (SPLIT). You leave (the bus is freed; other parties are seated) and you don't keep coming back to ask (the arbiter masks you — you're parked, not polling). When your table is ready, they text you (HSPLIT — the callback) and you come back and are seated (re-granted, complete OKAY). You wasted no trips asking, because they called you. The cost is that the restaurant needs your number and a texting system (HMASTER, HSPLIT, a split-aware host) — more infrastructure than just "come back and ask."

This captures SPLIT: take your number = HMASTER (remember the master); we'll text you = SPLIT + HSPLIT callback; you don't keep asking = arbiter masks the master (no polling); the texting system = the added complexity (HSPLIT bus, split-aware arbiter). The contrast with RETRY (chapter 7.3) is "come back and ask repeatedly" (poll) versus "we'll call you" (notify).

Watch the two-cycle SPLIT response:

The two-cycle SPLIT response

4 cycles
HRESP is OKAY then becomes SPLIT for two cycles. In the first SPLIT cycle HREADY is low (warning); in the second SPLIT cycle HREADY is high (transfer cancelled). The subordinate has recorded the master via HMASTER and will notify the arbiter via HSPLIT when ready, so the master is parked rather than polling.cycle 1: SPLIT + HREADY low — warningcycle 1: SPLIT + HREAD…cycle 2: SPLIT + HREADY high — cancelled; master parked (not polling)cycle 2: SPLIT + HREAD…HCLKHREADYHRESPOKAYSPLITSPLITOKAYt0t1t2t3
Figure 2 — the two-cycle SPLIT response. Like ERROR and RETRY, SPLIT spans two cycles: cycle T1 drives HRESP=SPLIT with HREADY low (warning), and cycle T2 drives HRESP=SPLIT with HREADY high (transfer cancelled). Unlike RETRY, the subordinate has recorded the master (HMASTER) and will later notify the arbiter via HSPLIT when ready, so the master is parked rather than polling. The waveform timing matches RETRY; the difference is the callback machinery off-screen.

The model's lesson: SPLIT is "we'll call you back" — the master is parked, not polling, and the subordinate notifies via HSPLIT when ready. In the waveform, the two-cycle SPLIT looks just like RETRY; the difference is invisible on these signals — it's the HMASTER recording and HSPLIT callback that distinguish it, eliminating the polling.

4. Real Hardware Perspective

In hardware, SPLIT is the fourth HRESP encoding in full AHB (OKAY/ERROR/RETRY/SPLIT), and it works through three pieces of machinery: HMASTER (master identity), HSPLIT (the callback bus), and a split-aware arbiter (masking/un-masking).

HMASTER is a signal, driven by the arbiter, carrying the ID of the master currently granted the bus (chapters on multi-master AHB). A SPLIT-capable subordinate samples HMASTER when it issues a SPLIT, recording which master's transfer it just split. So the subordinate maintains state: "master N is waiting on me." This per-master tracking is real hardware — the subordinate needs storage to remember which masters it has split (potentially several). For a subordinate that can split multiple masters, that's a small table of pending masters. This tracking is one of SPLIT's complexity costs.

HSPLIT is a bus with one bit per master (e.g., 16 bits for up to 16 masters), driven by the subordinate to the arbiter. When the subordinate becomes ready to complete a previously-split transfer, it asserts the bit corresponding to that master's ID on HSPLIT. This tells the arbiter "master N can now be re-granted to complete its split transfer." So HSPLIT is the readiness callback, encoded as a per-master bitmask. The arbiter watches HSPLIT and, on seeing a bit set, un-masks that master. HSPLIT is dedicated SPLIT infrastructure — extra wires that exist only for this mechanism.

The split-aware arbiter is the most complex piece. It must: (a) on a SPLIT response, mask the split master — exclude it from arbitration so it isn't granted (and doesn't poll); (b) watch HSPLIT and, when a master's bit is asserted, un-mask that master so it can be re-granted; (c) handle the bookkeeping of which masters are currently split-masked. So the arbiter carries significant added logic and state for SPLIT. This is a large part of why SPLIT is complex: it's not just a response value, it's a whole arbiter feature plus a signaling bus. By contrast, RETRY needs none of this — the master just re-issues through the normal arbitration.

A hardware subtlety: because the subordinate must track masters by ID, and the arbiter must mask/un-mask by ID, SPLIT couples the subordinate, the arbiter, and the master-identity signaling tightly — a system-wide feature, not a local one. So enabling SPLIT touches multiple components (subordinate tracking, HSPLIT routing, arbiter logic, HMASTER distribution). This system-wide footprint, for a feature that only helps with long-latency subordinates, is why many full-AHB systems didn't use SPLIT even when available, and why AHB-Lite dropped it. The complexity is real and pervasive, not contained.

5. System Architecture Perspective

At the system level, SPLIT is the most efficient of the legacy bus-freeing responses but also the most complex — and its cost/benefit, weighed against AHB-Lite's simplicity and AXI's native concurrency, is precisely why it (and RETRY) became historical footnotes.

SPLIT's system benefit is maximal multi-master throughput without polling: a slow subordinate frees the bus, other masters run, and the split master is re-granted exactly when its data is ready — no wasted retries. So in a heavily-contended multi-master full-AHB system with long-latency subordinates, SPLIT extracts the best bus utilization of the legacy options. This was its appeal: the efficiency of bus-freeing (like RETRY) without the polling waste. For its era and its target (busy multi-master AHB), SPLIT was the high-performance choice.

Side-by-side comparison of RETRY (poll, simple) versus SPLIT (notify via HMASTER/HSPLIT, efficient but complex).
Figure 3 — SPLIT versus RETRY: notify versus poll. Both free the bus, but RETRY makes the master poll (re-issue blindly, wasting attempts) with no extra signals, while SPLIT has the subordinate remember the master (HMASTER) and notify the arbiter when ready (HSPLIT) so the master is re-granted only when the data is available — efficient, but at the cost of a split-aware arbiter and per-master tracking. SPLIT trades RETRY's wasted polling for added complexity.

But SPLIT's complexity cost is system-wide, not localized: it requires HSPLIT routing to the arbiter, a split-aware arbiter with masking logic, per-master tracking in subordinates, and HMASTER distribution. So adopting SPLIT complicates the whole bus infrastructure, for a benefit that only materializes with long-latency subordinates under heavy contention. This poor cost/benefit — pervasive complexity for a narrow benefit — meant many systems skipped SPLIT even in full AHB, using simpler wait states or RETRY, or just isolating slow subordinates. The complexity was rarely worth it.

The historical verdict is the key architectural lesson. SPLIT (and RETRY) were superseded by two cleaner approaches. AHB-Lite dropped them entirely — most systems are single-master at the bus level (with an interconnect handling multiple masters), so the multi-master bus-freeing mechanisms were unnecessary complexity. AXI solved the underlying problem — slow subordinates under concurrency — far more elegantly with outstanding transactions: a slow subordinate's transaction is simply outstanding on AXI's independent channels while other transactions proceed, with native support for multiple in-flight transactions and out-of-order completion (by ID). AXI needs no SPLIT-like masking, no HSPLIT callback, no per-master subordinate tracking — concurrency is built into the channel architecture. So AXI achieves SPLIT's goal (slow subordinate doesn't block others) without SPLIT's machinery. The industry's move to AXI for concurrency, and AHB-Lite for simple buses, left SPLIT with no niche. It is the clearest case in AMBA of a feature whose complexity outweighed its benefit and was designed out of successors.

So SPLIT's system story: the most efficient legacy bus-freeing response, but with system-wide complexity that, weighed against AHB-Lite's simplicity and AXI's native concurrency, made it a dead end. Understanding SPLIT is mostly about understanding this evolution — why a clever mechanism lost to cleaner architectures.

6. Engineering Tradeoffs

SPLIT embodies the efficiency-via-complexity trade.

  • SPLIT (notify) vs RETRY (poll). SPLIT eliminates RETRY's wasted polling (re-granted only when ready) at the cost of HMASTER tracking, the HSPLIT bus, and a split-aware arbiter. RETRY is simple but wasteful; SPLIT is efficient but complex. The efficiency rarely justified the complexity.
  • Localized vs system-wide complexity. RETRY's complexity is localized (the master's re-issue logic). SPLIT's is system-wide (subordinate tracking + HSPLIT + arbiter + HMASTER). System-wide complexity for a narrow benefit is a poor trade — a key reason SPLIT was underused and then dropped.
  • Bus-freeing mechanisms vs native concurrency. SPLIT (and RETRY) bolt concurrency onto a shared single-transfer bus. AXI builds concurrency in (independent channels, outstanding transactions). Native concurrency is cleaner and more powerful, so the industry chose AXI over SPLIT/RETRY for concurrent workloads.
  • Multi-master feature vs single-master simplicity. SPLIT only helps multi-master buses; AHB-Lite (single-master) drops it for simplicity. Most systems found single-master AHB-Lite (with an interconnect for multi-master) simpler and sufficient, leaving SPLIT's multi-master machinery unused.

The throughline: SPLIT is the efficient-but-complex legacy bus-freeing response — it removes RETRY's polling by adding system-wide machinery (HMASTER, HSPLIT, a split-aware arbiter). Its pervasive complexity for a narrow benefit, weighed against AHB-Lite's simplicity and AXI's native concurrency, made it a historical dead end. SPLIT is the textbook example of an over-engineered feature designed out of successor protocols — valuable to understand for that lesson, not for new designs.

7. Industry Example

Trace SPLIT in a (legacy) multi-master full-AHB system, contrasting it with RETRY and AXI.

A full-AHB system has a CPU and a DMA sharing the bus, and a slow subordinate with long, variable latency (e.g., a controller waiting on an external resource).

  • The CPU hits the slow subordinate. The CPU issues a transfer; the subordinate will be busy for a long, variable time. It records the CPU's identity from HMASTER and returns SPLIT — cancel, free the bus, but remember the CPU.
  • The CPU is parked, the DMA runs. The arbiter masks the CPU (excludes it from arbitration) — so the CPU does not poll; it's parked, doing nothing on the bus. The arbiter grants the bus to the DMA, which makes full progress during the subordinate's long wait. No bus cycles are wasted on CPU retries (the RETRY waste is gone).
  • The subordinate calls back. When the subordinate is finally ready, it asserts the CPU's bit on HSPLIT. The arbiter sees it and un-masks the CPU, re-granting it.
  • The CPU completes. The CPU re-issues its transfer and completes OKAY — re-granted exactly when the data was ready, with zero wasted attempts. This is SPLIT's efficiency over RETRY: the CPU polled zero times.
  • The complexity behind it. Achieving this required: the subordinate tracking the CPU (per-master state), the HSPLIT bus routed to the arbiter, the arbiter's masking/un-masking logic, and HMASTER distribution. A lot of machinery for this one efficiency gain — and it only helped because the subordinate's wait was long.
  • What AXI does instead. On AXI, this is trivial and needs no special response: the CPU's transaction to the slow subordinate is simply outstanding on the read/write channels while the DMA's transactions to other subordinates proceed concurrently; the slow subordinate returns its data whenever ready (identified by transaction ID), and AXI's channels handle the rest. No SPLIT, no HSPLIT, no arbiter masking, no per-master tracking — concurrency is native. AXI gets SPLIT's benefit (slow subordinate doesn't block the DMA) with none of SPLIT's machinery.

The example shows SPLIT delivering on its promise (CPU parked efficiently, DMA running, CPU re-granted exactly when ready, zero polling) but at the cost of pervasive machinery — and shows AXI achieving the same outcome natively. This is the historical arc: SPLIT was the clever legacy solution; AXI's outstanding transactions made it obsolete.

8. Common Mistakes

9. Interview Insight

SPLIT is a classic legacy/history interview topic — and a favorite because explaining why it was dropped reveals architectural depth.

A summary card describing SPLIT's notify-not-poll mechanism via HMASTER and HSPLIT, and its complexity cost that led to its removal.
Figure 4 — a strong answer in one card: SPLIT is a legacy full-AHB two-cycle response that improves on RETRY by removing the polling — the subordinate remembers the master (HMASTER), the arbiter masks it so it doesn't poll, and when ready the subordinate asserts the master's bit on HSPLIT to re-grant it. The senior point: it costs a split-aware arbiter, the HSPLIT bus, and per-master tracking — complexity that AHB-Lite and AXI made unnecessary.

The answer that lands explains SPLIT as RETRY-without-polling and nails the trade-off: "SPLIT is a legacy full-AHB response that improves on RETRY. Both free the bus, but where RETRY makes the master poll (re-issue blindly), SPLIT has the subordinate remember which master it split — using HMASTER — and the arbiter masks that master so it doesn't poll; it's parked. When the subordinate is ready, it asserts that master's bit on the HSPLIT bus, and the arbiter un-masks and re-grants the master to complete. So SPLIT eliminates RETRY's wasted retries. But it costs a lot: HMASTER tracking in the subordinate, the HSPLIT bus, and a split-aware arbiter with masking logic — system-wide complexity. That's why, along with RETRY, it's full-AHB only and dropped in AHB-Lite and AHB5, and why AXI's outstanding transactions — which solve the same problem natively — superseded it." The notify-vs-poll distinction and the complexity-led-to-removal arc are the senior signals.

10. Practice Challenge

Reason from SPLIT's mechanism and historical verdict.

  1. Walk the flow. Describe the SPLIT sequence from issue to completion, naming HMASTER and HSPLIT's roles.
  2. Contrast with RETRY. Explain precisely how SPLIT eliminates RETRY's polling.
  3. List the machinery. Name the three pieces of hardware SPLIT requires and what each does.
  4. Explain the cost. Why is SPLIT's complexity considered system-wide and a poor trade?
  5. Historical verdict. Explain why SPLIT was dropped and how AXI solves the same problem.

11. Key Takeaways

  • SPLIT is a legacy full-AHB two-cycle response that improves on RETRY by eliminating the polling — the master is parked, not re-issuing blindly.
  • The subordinate remembers the master (via HMASTER) and, when ready, notifies the arbiter by asserting that master's bit on HSPLIT (a one-bit-per-master bus).
  • The arbiter masks the split master (so it doesn't poll) and un-masks/re-grants it on the HSPLIT notification — requiring a split-aware arbiter.
  • SPLIT's machinery is system-wide — HMASTER, HSPLIT, split-aware arbiter, per-master subordinate tracking — making it the most complex AHB feature.
  • SPLIT (and RETRY) are full-AHB only — dropped in AHB-Lite/AHB5, which keep just OKAY/ERROR.
  • SPLIT was superseded — its complexity outweighed its benefit; AHB-Lite removed the need, and AXI's outstanding transactions solve the same problem natively. The canonical "designed out" feature.

12. What Comes Next

You now understand both legacy bus-freeing responses. The next chapters return to details that apply to all responses:

  • 7.5 — Response Timing (coming next) — exactly when HRESP is sampled relative to HREADY, unifying the single-cycle (OKAY) and two-cycle (ERROR/RETRY/SPLIT) responses into one timing rule.
  • 7.6 / 7.7 (coming soon) — the detailed two-cycle ERROR handshake, and how the master reacts to each response.

To revisit the simpler sibling, see RETRY Response. For the responses every version has, see OKAY Response and ERROR Response. For why AXI superseded this approach, see AXI vs AHB vs APB. For the broader protocol map, see the AMBA family overview.