Worked examples — IP cores and SoC bus fabric

This page is the "prove it on every case" companion to the parent topic. The parent told you what AXI channels, crossbars, and APB/AHB/AXI throughput are. Here we grind through every kind of numeric question this topic can throw at you — the small easy ones, the degenerate ones (one master, zero outstanding transactions), the limiting ones (infinite burst length), a real-world word problem, and an exam-style twist that hides a trap.

Before any formula appears we rebuild it in plain words, so you never meet a symbol you have not been introduced to.

---

The scenario matrix

Every question on bus fabric throughput and crossbar sizing falls into one of these case classes. Think of it as a checklist: if you can answer one example from each row, nothing on an exam can surprise you.

#	Case class	What makes it tricky	Covered by
A	Simple throughput (fixed cycles/transfer)	just plug numbers	Ex 1
B	Burst amortization (overhead spread over N beats)	the "+overhead" term	Ex 2
C	Degenerate input — burst length = 1	overhead dominates, formula must still work	Ex 3
D	Limiting input — burst length → ∞	throughput approaches a ceiling	Ex 4
E	Parallelism (multiple outstanding transactions)	multiply, but watch the real bottleneck	Ex 5
F	Crossbar sizing (counting switches/arbiters)	$N\times M$ growth, degenerate $N=1$	Ex 6
G	Real-world word problem — meet a bandwidth budget	translate MB/s ↔ bits, pick a protocol	Ex 7
H	Exam twist — the trap: bus width vs. clock vs. efficiency all change at once	don't mix up bits and bytes	Ex 8

The two tools we reuse everywhere:

---

Ex 1 — Case A: the plain APB transfer

Forecast: guess before reading — will it beat or lose to a 1-cycle bus? (It must lose, because 2 cycles is slower than 1.)

Steps

1. Identify $W=32$ bits, cycles-per-transfer $=2$, $f_{\text{clk}}=100\times 10^6$ Hz. Why this step? Tool 1 needs exactly these three numbers; naming them first stops us mixing them up.

2. Apply Tool 1: $\frac{32\text{bits}}{2\text{cycles}}\times 100\times 10^6\text{Hz}=16\times 100\times 10^6=1.6\times 10^9\text{bits/s}.$ Why this step? This is the raw bit-rate before converting units.

3. Convert bits → bytes (divide by 8): $\frac{1.6\times 10^9}{8}=200\times 10^6\text{bytes/s}=200\text{MB/s}.$ Why this step? MB/s is the unit the question asked for.

Verify: Sanity — 2 cycles is half the speed of a 1-cycle bus, and a 1-cycle 32-bit 100 MHz bus is $400$ MB/s. Half of 400 is 200 ✓. Matches the parent note's APB figure.

---

Ex 2 — Case B: AHB burst, overhead amortized

Forecast: more than 200 MB/s (better than APB) but less than the ideal 400 MB/s — because 2 wasted cycles are hiding among the 8 useful ones.

Steps

1. Plug $W=32$, $L=8$, $c=2$ into Tool 2. Why this step? This is exactly the "useful cycles vs total cycles" idea. $\text{Throughput}=\frac{32\times 8}{8+2}\times 100\times 10^6=\frac{256}{10}\times 100\times 10^6=2.56\times 10^9\text{bits/s}.$

2. Convert to bytes: $2.56\times 10^9/8=320\times 10^6=320\text{MB/s}$. Why this step? Answer requested in MB/s.

Verify: Efficiency $=L/(L+c)=8/10=80\%$. And $80\%$ of the ideal $400$ MB/s $=320$ MB/s ✓.

---

Ex 3 — Case C: degenerate burst, $L=1$

Forecast: this should collapse toward APB-like numbers, because with only 1 useful word the 2 overhead cycles dominate.

Steps

1. Put $L=1$ into Tool 2. Why? A degenerate case must not break the formula — plug it in honestly. $\text{Throughput}=\frac{32\times 1}{1+2}\times 100\times 10^6=\frac{32}{3}\times 100\times 10^6\approx 1.067\times 10^9\text{bits/s}.$

2. Convert: $1.067\times 10^9/8\approx 133.3\text{MB/s}$.

Verify: Efficiency $=1/3\approx 33.3\%$. This is worse than APB's 200 MB/s — makes sense: an un-batched single word wastes most cycles on setup, so bursting is pointless for lone accesses. That's the whole reason bursts exist.

---

Ex 4 — Case D: limiting behaviour, $L\to \infty$

Forecast: it should approach the ideal 400 MB/s but never exceed it — the fixed 2 cycles become negligible when spread over millions of beats.

The figure shows efficiency $L/(L+c)$ climbing toward 1 as $L$ grows:

Steps

1. Take the limit of Tool 2 as $L\to \infty$. Why a limit? "As $L$ grows huge" is precisely the question a limit answers — it tells us the value the curve creeps up to but never crosses. ${\lim }_{L\to \infty }\frac{WL}{L+c}=W\cdot {\lim }_{L\to \infty }\frac{L}{L+c}=W\cdot 1=W.$ (Divide top and bottom by $L$: $\frac{1}{1+c/L}\to \frac{1}{1+0}=1$.)

2. So throughput $\to W\times f_{\text{clk}}=32\times 100\times 10^6=3.2\times 10^9$ bits/s $=400\text{MB/s}$.

Verify: Look at the red curve in the figure: it flattens toward the dashed ceiling and never touches it — exactly what a limit describes. The overhead is amortized to zero.

---

Ex 5 — Case E: AXI parallelism (multiple outstanding)

Forecast: roughly 4× a single burst — but only if the slave and wires can actually carry it.

Steps

1. Single-burst throughput (Tool 2): $\frac{32\times 16}{16+2}\times 100\times 10^6=\frac{512}{18}\times 100\times 10^6\approx 2.844\times 10^9\text{bits/s}\approx 355.6\text{MB/s}.$ Why this step? We need the per-transaction number before multiplying.

2. Multiply by 4 outstanding transactions: $4\times 355.6\approx 1422\text{MB/s}.$ Why this step? Outstanding transactions overlap in time, so their throughputs add — up to a limit.

Verify: $355.6\times 4=1422$ MB/s ✓ (matches the parent's ≈1400 MB/s estimate).

---

Ex 6 — Case F: crossbar sizing (and degenerate $N=1$)

Forecast: (a) switches grow as $N\times M$ so expect 32; arbiters and comparators one-per-slave = 8 each. (b) with one master there's nothing to arbitrate.

The crossbar grid — each red dot is one switch:

Steps

1. Switches $=N\times M=4\times 8=32$. Why? Every master needs a possible path to every slave; that's one crosspoint per (master, slave) pair — count the red dots.

2. Arbiters $=M=8$. Why? Each slave might be requested by several masters at once; one referee per slave picks a winner.

3. Address comparators $=M=8$. Why? Each slave owns an address range; one comparator decides "is this address mine?"

4. Degenerate $N=1$: switches $=1\times 8=8$, but arbiters $=M=8$ still exist structurally, though each has only one requester → they never actually arbitrate. Why note this? An exam may claim "you can drop the arbiters when $N=1$." Structurally they're one-per-slave; logically they degenerate to pass-through. Say both.

Verify: Complexity is $O(N\times M)$: doubling $N$ to 8 gives $8\times 8=64$ switches — exactly double. Linear in each dimension ✓.

---

Ex 7 — Case G: real-world word problem

Forecast: 4K60 is famously "a few GB/s". A 64-bit 200 MHz link is $\approx 1.6$ GB/s at peak — this will be close, so compute carefully.

Steps

1. Bytes per frame: $3840\times 2160\times 3=24,883,200$ bytes. Why? Total data per frame is width × height × bytes-per-pixel.

2. Required bandwidth: $\times 60$ frames/s: $24,883,200\times 60=1,492,992,000\text{bytes/s}\approx 1493\text{MB/s}.$ Why? 60 frames every second, so multiply per-frame by 60.

3. Link peak: $W=64$ bits at $200\times 10^6$ Hz: $64\times 200\times 10^6=12.8\times 10^9\text{bits/s}=1600\text{MB/s}.$

4. Usable at $90\%$: $1600\times 0.9=1440\text{MB/s}$. Why? Real fabrics never reach peak; the efficiency factor accounts for overhead cycles.

5. Compare: need $\approx 1493$ MB/s, have $1440$ MB/s. The link is NOT enough — short by $\approx 53$ MB/s.

Verify: $1493>1440$ ✓, so the answer "no" is correct. Fix options: widen to 128-bit, raise clock, or add compression. Units check: bytes/s vs bytes/s throughout ✓.

---

Ex 8 — Case H: the exam twist (everything changes at once)

Forecast: don't eyeball it — the numbers are engineered to be close.

Steps

1. Bus X: $16\times 250\times 10^6=4.0\times 10^9$ bits/s $=500\text{MB/s}$. Why? Tool 1 with 1 cycle/transfer reduces to $W\times f_{\text{clk}}$.

2. Bus Y: $32\times 100\times 10^6=3.2\times 10^9$ bits/s $=400\text{MB/s}$.

3. Compare: Bus X wins, $500>400$ MB/s. Why the surprise? Width and clock both matter as a product. The narrower bus's higher clock more than compensates. Never assume "wider = faster".

Verify: $16\times 250=4000$ and $32\times 100=3200$; ratio $4000/3200=1.25$, so Bus X is $25\%$ faster ✓. In bytes: $500$ vs $400$ ✓.

---

Recall

Recall Why does a burst of

$L=1$ make AHB slower than APB? With one useful word and 2 overhead cycles, efficiency is $1/3$; bursting only pays off when many words share one address phase. ::: Overhead dominates a single-word transfer.

Recall As burst length

$L\to \infty$, what throughput does $\frac{WL}{L+c}{f}_{\text{clk}}$ approach and why? It approaches $W{f}_{\text{clk}}$ — the ceiling — because the fixed $c$ cycles are amortized to zero. ::: The peak width×clock rate.

Recall On a single 32-bit channel, why can't 4 outstanding AXI transactions give 4× bandwidth?

The wire still carries only $W{f}_{\text{clk}}$ bits/s; outstanding transactions hide latency, not add wire capacity. Real 4× needs multiple physical channels. ::: The channel is still the physical bottleneck.

Recall Full crossbar with

$N$ masters and $M$ slaves: how many switches, arbiters, comparators? $N\times M$ switches, $M$ arbiters, $M$ comparators. ::: NM, M, M.

See also: Interconnect Topologies · DMA · Memory-Mapped I/O · DRAM Controllers · PCIe · Cache Coherence Protocols · Power Management