AMBA AXI · Module 12

Crossbar Architecture

The AXI crossbar topology — full N×M connectivity enabling concurrent manager-subordinate transfers, per-subordinate arbitration, the quadratic area cost, and the sparse-crossbar optimization that trades connectivity for area.

The crossbar is the highest-performance AXI interconnect topology — a switch matrix giving full N×M connectivity where multiple manager-subordinate pairs transfer simultaneously. It's how a high-bandwidth fabric lets a CPU hit DRAM while a DMA hits a different memory at the same time, with no serialization. The cost is area: full connectivity grows roughly with N×M. This chapter covers how a crossbar achieves concurrency, where arbitration is still needed, its quadratic area cost, and the sparse crossbar optimization that wires only the connections that matter.

1. Full N×M Connectivity and Concurrency

A crossbar is a switch matrix: each of the N managers can be connected to each of the M subordinates. The defining property is concurrency — as long as two managers target different subordinates, both transfers proceed in parallel, independently. There's no shared path to serialize them.

This is the crossbar's whole value: aggregate bandwidth scales with the number of concurrent non-conflicting pairs (up to min(N, M) simultaneous transfers). A CPU reading DRAM, a DMA writing a peripheral, and a GPU reading a second memory can all transfer at once — three parallel paths through the matrix. Contrast a shared bus, where only one transfer happens at a time regardless of targets.

Figure 1 — a crossbar provides full N×M connectivity: a switch matrix where any manager can connect to any subordinate. Multiple manager-subordinate pairs targeting different subordinates transfer concurrently through independent matrix paths — the source of the crossbar's high aggregate bandwidth (up to min(N,M) simultaneous transfers).

2. Where Arbitration Is Still Needed

Concurrency holds only for different subordinates. When two or more managers target the same subordinate, they contend for that one port, and an arbiter at the subordinate decides the order (Chapter 12.4). So a crossbar has per-subordinate arbitration: each subordinate port has an arbiter resolving the managers competing for it, while different subordinates run independently.

This is the key structural insight: a crossbar distributes arbitration to each subordinate port rather than having one global arbiter. M0→S0 and M1→S1 never arbitrate against each other (different ports), but M0→S0 and M1→S0 do (same port). So contention — and the throughput cost of arbitration — is localized to each shared subordinate, and traffic to distinct subordinates is fully parallel. A well-distributed address map (spreading hot traffic across subordinates) maximizes the crossbar's concurrency.

Figure 2 — concurrency vs contention. Managers targeting different subordinates (M0→S0, M1→S1) transfer in parallel — no arbitration. Managers targeting the same subordinate (M0→S0, M1→S0) contend, resolved by a per-subordinate arbiter. The crossbar localizes arbitration to each shared subordinate port; distinct-subordinate traffic is fully concurrent.

3. The Area Cost

Full connectivity isn't free. A full crossbar must provide a path from every manager to every subordinate, so the switching/muxing and wiring grow roughly with N × M — quadratic in the number of ports. And because AXI has five channels, each needing routing, the cost multiplies further. For small N, M this is fine; for large port counts it becomes a real burden: wiring congestion, deep multiplexers (adding latency), and significant silicon area.

So the crossbar's bandwidth advantage trades directly against area: it's the most concurrent topology and the most expensive. This is why you don't make the entire SoC one giant crossbar — a 20-manager × 30-subordinate full crossbar would be enormous and congested. Instead, crossbars are used where the bandwidth is needed (CPUs/DMA/memory) and kept reasonably sized, with cheaper topologies elsewhere.

Figure 3 — the crossbar's cost. Full N×M connectivity means switching/wiring grows ~quadratically with port count (×5 for AXI's five channels), causing wiring congestion, deeper muxes (latency), and large area. Bandwidth (concurrency) trades directly against area — the crossbar is the most concurrent and the most expensive topology, so it's used where bandwidth is needed, not everywhere.

4. The Sparse Crossbar

The optimization that makes crossbars practical: not every manager needs to reach every subordinate. A DMA might only touch DRAM and one peripheral; a peripheral-control master might never touch high-speed memory. A sparse (partial) crossbar wires only the manager-subordinate connections that actually communicate, omitting the rest — dramatically cutting area and congestion while keeping full concurrency for the connections that exist.

So a real high-performance interconnect is usually a sparse crossbar: the connectivity map reflects the actual traffic pattern (derived from which masters access which slaves), and unused crossings are simply not built. This is the practical middle ground — most of the crossbar's concurrency benefit at a fraction of the full-crossbar area. Combined with hierarchy (Chapter 12.1) — a sparse crossbar for the high-bandwidth core, shared/bridged segments for peripherals — it's how SoCs get the bandwidth they need without quadratic area everywhere.

Figure 4 — the sparse crossbar. Since not every manager accesses every subordinate, a sparse crossbar wires only the connections that actually communicate (per the real traffic map) and omits the rest — cutting area/congestion while keeping full concurrency for the connections that exist. Combined with hierarchy, it's how SoCs get crossbar bandwidth without quadratic area.

5. Common Misconceptions

Myths to unlearn

"A crossbar serializes traffic like a bus." The opposite — it enables concurrent transfers; managers targeting different subordinates run fully in parallel. Only same-subordinate access contends.
"A crossbar has one global arbiter." No — it has per-subordinate arbitration. Each subordinate port arbitrates its contending managers independently; different subordinates don't arbitrate against each other.
"A crossbar gives unlimited concurrency." Up to min(N, M) simultaneous transfers (and only for non-conflicting pairs). Two managers hitting one subordinate still serialize at that port.
"Full crossbars are used SoC-wide." Too expensive — full N×M is ~quadratic area. Real SoCs use sparse crossbars (only real connections) within a hierarchy, not one giant full crossbar.
"Sparse crossbars lose concurrency." They keep full concurrency for the connections that exist — they only drop unused crossings, so traffic that actually happens is unaffected.
"The crossbar is just wiring." It's a switch matrix with per-manager routing and per-subordinate arbitration — active logic whose area scales with connectivity.

6. Debugging Insight

🔍 Debugging insight — concurrency, contention, and connectivity issues

Crossbar issues are about whether traffic is actually parallel and reaches its target:

Expected concurrency but transfers serialize? The managers are targeting the same subordinate (contending at its arbiter), or the address map funnels traffic to one port. Spread hot traffic across subordinates so the crossbar can parallelize it; check which subordinate each access hits.
A manager can't reach a subordinate at all? In a sparse crossbar, that connection may not be wired — the connectivity map omitted it. Confirm the manager-subordinate pair is actually connected; if it should be, the sparse map is wrong.
One subordinate is a bottleneck? Many managers contend for it (per-subordinate arbitration serializes them). It's inherent to that port's sharing — mitigate with QoS, more banks/ports, or by distributing the data across subordinates.
Throughput below expectation despite a crossbar? Possibly the crossbar's buffering/outstanding depth per path limits it (8.5), or the address map concentrates traffic. Check per-path depth and traffic distribution.
Area/timing closure failing on the fabric? A full crossbar too large for the port count — wiring congestion / deep muxes. Sparsify it (remove unused connections) or restructure hierarchically.

The triage: serialized-when-shouldn't → same-subordinate contention or skewed address map; can't-reach → sparse connectivity gap; one slow port → per-subordinate contention; area/timing → over-full crossbar. Match the symptom to concurrency, connectivity, or cost.

7. Verification Insight

✅ Verification insight — prove concurrency, contention handling, and connectivity

Crossbar verification proves the topology delivers concurrency and routes correctly. Concurrency: drive multiple managers to different subordinates simultaneously and assert they transfer in parallel (no false serialization) — measure aggregate bandwidth approaching min(N,M) × per-path rate. Contention: drive multiple managers to the same subordinate and assert the per-subordinate arbiter resolves them fairly with no data loss or misrouting. Connectivity: for a sparse crossbar, verify every wired connection works and (per spec) accesses to unwired connections are handled as defined (typically DECERR or simply not generated by a correct master). Protocol preservation: AXI compliance on every port and end-to-end data integrity (each manager's transactions reach the right subordinate, responses route home — the Chapter 12.1 requirement) under concurrent load.

Coverage should include: all wired manager-subordinate pairs; maximum concurrent non-conflicting pairs (full parallelism); maximum contention (all managers to one subordinate); mixed concurrent + contending traffic; and full-load with buffers filled. The highest-value tests are max-concurrency (proves the crossbar actually parallelizes — a serialization bug here silently kills the bandwidth the crossbar exists for) and max-contention (proves arbitration fairness and integrity at a shared port). Because the crossbar's reason for existing is concurrency, verifying that the concurrency is real — not silently serialized by a bug — is the central check.

8. Interview Questions

9. Summary

The crossbar is AXI's highest-bandwidth interconnect topology — a switch matrix with full N×M connectivity where managers targeting different subordinates transfer concurrently (up to min(N,M) simultaneous pairs), giving aggregate bandwidth that scales with concurrent flows. Arbitration is needed only at shared subordinate ports (per-subordinate arbiters), so contention is localized and distinct-subordinate traffic is fully parallel — making a well-distributed address map essential to actually realize the concurrency. The cost is ~quadratic area (×5 for AXI's channels): wiring congestion, deep muxes, large silicon, which is why full SoC-wide crossbars aren't used.

The practical answer is the sparse crossbar — wire only the connections that actually communicate (per the real traffic map), keeping full concurrency for existing connections at a fraction of full-crossbar area — typically within a hierarchy (sparse crossbar for the high-bandwidth core, shared/bridged for peripherals). Its bugs are false serialization (concurrency silently lost), connectivity gaps (sparse map missing a needed link), and per-port bottlenecks (skewed address map). The single most important verification is proving the concurrency is real — a serialization bug yields correct data but wastes the crossbar's whole purpose, and only performance/concurrency testing catches it. Next: the decoder and address map — how the crossbar actually decodes AxADDR to select a subordinate port.

10. What Comes Next

You've got the crossbar topology; next, the decode that drives it:

12.3 — Decoder & Address Map (coming next) — how the decoder maps addresses to subordinate ports, and the address-map structure behind routing.
12.4 — Arbiter & Arbitration (coming soon) — the per-subordinate arbitration policies (round-robin, priority, QoS) that resolve contention.

Previous: 12.1 — AXI Interconnect Overview. Related: 8.5 — Interconnect Implications for the concurrency/buffering view. For the broader protocol catalog, see the AMBA family overview doc.