Worked examples — System-on-Chip (SoC) integration

This page is the drill hall for the parent topic. The parent told you what the pieces are (IP blocks, interconnect, CDC, power domains). Here we throw every kind of scenario at you and work each one to a number, so that on the exam or in a real design review you never meet a case you have not already seen.

Before any formula appears, remember the four number-producing tools this topic uses. We will re-earn each one as it shows up. Every symbol is defined the moment it appears:

• Crossbar bandwidth $B_{\text{total}}=\min (M,N)\times B$ — where $M$ = number of masters (things that issue requests, e.g. CPU), $N$ = number of slaves (things that answer, e.g. memory), $B$ = bandwidth of one link in GB/s. Answers "how many transfers can happen at once?"
• Metastability MTBF $\text{MTBF}\propto e^{T_{\text{wait}}/\tau }$ — where $T_{\text{wait}}$ = time we give a flop to settle, $\tau$ = the transistor's settling time-constant. Answers "how long between crashes if I wait $T_{\text{wait}}$?"
• Dynamic power $P_{\text{dyn}}=\alpha C{V}^{2}f$ — where $\alpha$ (activity factor) = the fraction of clock cycles on which a node actually switches (a pure number between 0 and 1; if a wire toggles every other cycle, $\alpha =0.5$), $C$ (capacitance) = the electrical "bucket size" of all the wires being charged, in farads (bigger nodes store more charge), $V$ = supply voltage, $f$ = clock frequency. Answers "how much energy per second does switching burn?"
• Address decode address[31:12] == base — full derivation of this notation is done fresh in Example 7 (do not trust the shorthand until then). For now read it loosely as "does this request's high bits match a peripheral's start tag?" Answers "which slave owns this request?"

---

The scenario matrix

Every SoC-integration question is one cell of this grid. The worked examples below are tagged with the cell(s) they cover, so by the end every cell is filled.

Cell	Case class	What makes it tricky	Covered by
A	Crossbar — best case ($M\le N$, all distinct)	max parallelism	Ex 1
B	Crossbar — worst case (all target one slave)	serialization	Ex 1
C	Crossbar — degenerate ($N=1$, single memory)	$\min (M,1)=1$	Ex 2
D	Crossbar — $M>N$ (more masters than slaves)	ports on slave side limit	Ex 2
E	CDC — single bit, MTBF sizing	exponential in wait time	Ex 3
F	CDC — multi-bit bus, tiny-but-nonzero failure	2-flop fails, must switch tool	Ex 4
G	Power — steady power-gating savings + overhead	duty cycle weighting, break-even	Ex 5
H	Power — voltage scaling (DVFS), $V^2$ law	quadratic in $V$	Ex 6
I	Address map — no overlap / decode	half-open ranges, off-by-one traps	Ex 7
J	Word problem (real phone SoC)	pick the right tool	Ex 8
K	Exam twist (combine two tools)	interconnect and power together	Ex 9
L	Limiting behaviour ($T_{\text{wait}}\to 0$, $V\to 0$)	edge sanity checks	Ex 10

---

Example 1 — Crossbar best case vs worst case (cells A, B)

Forecast: guess before reading. Best case should be "several links at once"; worst case should be "just one link". Write your two numbers down.

Figure caption — the crossbar grid. Each row is a master (CPU, GPU, DMA, DSP), each column is a slave (S0…S5). A cell at (row $i$, column $j$) is the possible path from master $i$ to slave $j$. A lit amber cell is an active transfer this cycle. The rule the picture enforces: the crossbar can light at most one cell per row (a master issues one thing at a time) and one cell per column (a slave answers one master at a time). The four amber cells drawn all sit in different rows and different columns — that is the best case, and counting them gives you the answer to part (a) directly. Now the steps:

1. Count how many cells can be lit at once. Using the "one-per-row and one-per-column" rule you can see in the figure, the maximum number of simultaneously lit cells is the smaller of #rows and #columns. Why this step? This is exactly why the tool is $\min (M,N)$ and not $M+N$ or $M\times N$ — a slave with a single port (one column) cannot answer two masters in the same cycle, so lit cells can never exceed the number of columns, nor the number of rows.
2. Plug in for best case. $\min (M,N)=\min (4,6)=4$. So $B_{\text{total}}=4\times 8=32$ GB/s. Why this step? $M\le N$ means every master can find its own distinct slave (its own column) → all four transfer in parallel, exactly the four amber cells in the figure.
3. Worst case: all target slave 0. Now only column 0 can be lit, and only one cell in it. So one transfer: $B_{\text{total}}=1\times 8=8$ GB/s. Why this step? Arbitration serializes the four requests through the single port (single column) of slave 0.

Verify: Best case $32$ GB/s is $4\times$ the single-link $8$ GB/s — matches "4 parallel lanes" = 4 lit cells. Worst case $8$ equals one link — matches "everyone queues" = one lit cell. Units: (links)$\times$(GB/s) = GB/s. ✓

---

Example 2 — Single memory & more masters than slaves (cells C, D)

Forecast: (a) is a degenerate case — one door for eight people. (b) has more masters than doors.

Figure caption — two collapsed grids. Left grid: $8$ rows (masters) but only one column, so at most one amber cell lights — the crossbar has degenerated into a shared bus. Right grid: $8$ rows, $3$ columns, with three amber cells in distinct columns — the slave side (3 columns) caps how many can light, no matter how many rows crowd in. The picture makes $\min (M,N)$ obvious: count the columns whenever there are fewer columns than rows.

1. (a) Apply $\min (M,N)$. $\min (8,1)=1$, so $B_{\text{total}}=1\times 6=6$ GB/s. Why this step? One slave = one port = one transfer per cycle, no matter how many masters. The extra 7 masters just wait — the crossbar collapses to a shared bus (left grid).
2. (b) Slave side is the bottleneck. $\min (8,3)=3$, so $B_{\text{total}}=3\times 6=18$ GB/s. Why this step? Even with 8 eager masters, only 3 slaves can answer at once. When $M>N$, the answer is capped by $N$ — the master count stops mattering above $N$ (right grid, 3 lit columns).

Verify: In (a), adding masters never raises bandwidth past $6$ — sanity: a single memory cannot exceed its own port. In (b), $18=3\times 6$ and $3=N<M$ so the cap sits on the slave side. ✓

---

Example 3 — CDC single-bit synchronizer MTBF (cell E)

First we must earn the MTBF tool. When the first flop of a synchronizer samples a signal that is changing, its output can hang at a half-voltage ("metastable") for a while before snapping to 0 or 1. The chance it is still undecided after waiting a time $T_{\text{wait}}$ shrinks like $e^{-T_{\text{wait}}/\tau }$, where $\tau$ (~$0.1$ ns) is how fast the transistor "makes up its mind". Because failures get rarer exponentially, the mean time between failures is

$\text{MTBF}=\frac{e^{T_{\text{wait}}/\tau }}{T_0{f}_{\text{clk}}{f}_{\text{data}}}$

What are the two device constants, physically? A metastable flop behaves like a ball balanced on a hill: the further off-centre it starts, the faster it rolls off. $\tau$ (resolution time-constant, units: seconds, ~$0.1$ ns) is how fast it rolls — a property of the transistor's gain and load, so bigger/faster transistors give smaller $\tau$ and settle sooner. $T_0$ (metastability window constant, units: seconds, ~$1$ ns) measures how wide the "danger window" around the clock edge is — the sliver of input arrival times that can trigger a metastable event at all. It comes from the flop's aperture (setup+hold region) and is measured on the bench for a given cell. Together the denominator $T_0{f}_{\text{clk}}{f}_{\text{data}}$ counts metastable events attempted per second: how wide the window is ($T_0$) $\times$ how often we sample ($f_{\text{clk}}$) $\times$ how often the data toggles into that window ($f_{\text{data}}$). The exponential numerator then says how many of those attempts survive the wait. We use the exponential, not a linear model, because settling is a decay process — the deeper you wait, the disproportionately safer you get.

Figure caption — the resolution decay. The amber curve is $e^{-T_{\text{wait}}/\tau }$: the probability a flop is still undecided after waiting $T_{\text{wait}}$. It falls off a cliff. The vertical cyan lines mark $T_{\text{wait}}=2$ ns (2-flop) and $4$ ns (3-flop) — see how the second flop pushes you far down the tail.

Forecast: $T_{\text{wait}}/\tau =2/0.1=20$, and $e^{20}$ is enormous, so expect years, not seconds.

1. Compute the exponent. $T_{\text{wait}}/\tau =2\text{ ns}/0.1\text{ ns}=20$, and $e^{20}\approx 4.85\times 10^8$. Why this step? This factor is the whole payoff of adding the second flop.
2. Compute the denominator (failures/second scale). $T_0{f}_{\text{clk}}{f}_{\text{data}}=(10^{-9})(5\times 10^8)(10^7)=5\times 10^6$ s${}^{-1}$. Why this step? This is how often a metastable event is even attempted — more clocking and more toggling means more chances to fail.
3. Divide. $\text{MTBF}=\frac{4.85\times 10^8}{5\times 10^6}\approx 97$ s. Why this step? Yields the actual mean time — here it's tiny, telling us 2 flops is not enough at these rates.

Verify: $97$ s is embarrassingly short — good, it demonstrates why fast/heavily-toggling signals need a third flop (add another $2$ ns): the exponent jumps to $40$, $e^{40}\approx 2.35\times 10^{17}$, MTBF $\approx 4.7\times 10^{10}$ s $\approx$ 1500 years. Exponential wait wins decisively. ✓

---

Example 4 — Multi-bit bus: 2-flop failure probability (cell F)

Forecast: feels like it should "mostly work". Let's put a number on the failure.

1. Model one bit's skew probability. Each of the 32 bits synchronizes independently. When several bits change on the same source cycle, any one bit can resolve one destination cycle late if it went metastable and settled slowly. Let $p$ be the probability a given transitioning bit resolves one cycle late; from the same physics as Example 3, $p\approx e^{-T_{\text{wait}}/\tau }$ per event — small, but strictly greater than zero. Why this step? We replace the vague "it might break" with a real per-bit probability so we can add up 32 bits.
2. Combine across the bus. The word is captured wrong if at least one of the (up to) 32 bits is skewed. With $k$ bits transitioning together, the chance the whole word is captured cleanly is $(1-p{)}^k$, so $P_{\text{corrupt}}=1-(1-p{)}^k\approx kp(\text{for small }p).$ Why this step? Independent bits multiply; the failure probability grows roughly linearly with the number of bits changing. It is tiny but not zero — and it recurs on every multi-bit change, so over billions of transfers corruption is inevitable. (This is the correction: not "absolute zero probability", but "small $p$ per bit, $\approx kp$ per word, accumulating to certain failure over time".)
3. Switch the tool so $k$ effectively becomes 1. Use a handshake (hold the 32 bits static, synchronize only a 1-bit valid) or an async FIFO with Gray-coded pointers so only one pointer bit changes per step. Why Gray code? Because a single-bit change makes $k=1$, collapsing $P_{\text{corrupt}}\approx kp$ back to the single-bit MTBF we already sized safely in Example 3.

Verify: With $p$ small and $k=32$, $P_{\text{corrupt}}\approx 32p$ — thirty-two times worse than one bit, and never exactly zero. Reducing to $k=1$ recovers Example 3's reliability. Consistency: 1 bit ⇒ Example 3 applies; 32 bits ⇒ must reduce control to 1 bit. ✓ See Clock Domain Crossing Techniques and AXI Protocol for the async bridge that does this.

---

Example 5 — Power-gating savings and its break-even (cell G)

Forecast: (a) ≈ "leakage times off-fraction". (b) overhead is tiny per event but multiplied by frequency of gating.

1. (a) Baseline (idle-powered) average. $0.15\times 1.5+0.85\times 0.4=0.225+0.34=0.565$ W. Why this step? Weight each state by its fraction of time — that is what "average power" means.
2. (a) Ideal power-gated average. Active still $0.15\times 1.5=0.225$ W; off state draws $\approx 0$: total $=0.225$ W. Naive savings $=0.565-0.225=0.34$ W. Why this step? Power-gating removes both dynamic and static power in the off window; the removed part is exactly the $0.85\times 0.4=0.34$ W of leakage.
3. (b) Add the transition penalty. Waking $n=200$ times/s at $E_{\text{wake}}=0.5$ mJ costs $P_{\text{overhead}}=n\times E_{\text{wake}}=200\times 0.5\times 10^{-3}=0.1$ W. Why this step? Each on/off cycle re-charges the domain's capacitance — that energy, times how often you do it, is a continuous power cost that eats into the $0.34$ W saved.
4. (b) Net savings. $0.34-0.1=0.24$ W still saved. Break-even is where $n\times E_{\text{wake}}=0.34$ W, i.e. $n_{\text{max}}=0.34/0.5\text{e-}3=680$ gate cycles/s. Above that, gating loses. Why this step? Quantifies the parent note's warning: power-gating only pays when the block stays off long enough that leakage saved > wake-up energy. The $t_{\text{wake}}=50\mu$s latency also means you must not gate a block needed again within $\sim$tens of $\mu$s.

Verify: Overhead $=200\times 0.5\text{ mJ}=0.1$ W; net $=0.34-0.1=0.24$ W $>0$ ⇒ worth it here. Break-even $n=0.34/0.0005=680$/s; our $200<680$ ✓. Units: (events/s)$\times$(J) = W. ✓ See Power Management in SoCs.

---

Example 6 — DVFS and the $V^2$ law (cell H)

Here the tool is $P_{\text{dyn}}=\alpha C{V}^{2}f$. We use $V^2$, not $V$, because each switching node charges a capacitor $C$ to voltage $V$, storing energy $\frac{1}{2}C{V}^2$ — energy scales with the square. That is why lowering voltage is the single most powerful knob.

Forecast: both $V^2$ (0.64$\times$) and $f$ (0.6$\times$) drop — expect roughly one-third of original.

Figure caption — two bars. The tall amber bar is $P_1\propto V_1^2{f}_1=2.0$ (arbitrary units); the short cyan bar is $P_2\propto V_2^2{f}_2=0.768$. The gap you can see is the $61.6\%$ removed. Note the voltage contribution ($0.64$) does more work than the frequency contribution ($0.6$) — the square bites harder.

1. Form the ratio so $\alpha ,C$ cancel. $\frac{P_2}{P_1}=\frac{V_2^2{f}_2}{V_1^2{f}_1}=\frac{(0.8{)}^2(1.2)}{(1.0{)}^2(2.0)}.$ Why this step? Only the changing quantities matter for a fractional answer; the constant activity factor $\alpha$ and capacitance $C$ divide out top and bottom.
2. Compute. $(0.8{)}^2=0.64$; $0.64\times 1.2=0.768$; $0.768/2.0=0.384$. Why this step? Multiply the voltage-square factor by the frequency factor.
3. Interpret. $P_2/P_1=0.384$, so power falls to $38.4\%$ — a $61.6\%$ reduction. Why this step? A ratio is meaningless until we translate it into "how much did we save?"; $1-0.384=0.616$ is the fraction of power removed, which is the number an engineer actually reports to justify the DVFS state.

Verify: Reduction $=1-0.384=0.616$. Cross-check the two knobs separately: voltage alone $0.64$, frequency alone $0.6$; product $0.384$. ✓ This is why phones cut voltage and clock together.

---

Example 7 — Address map: half-open ranges and decode (cell I)

Before any hex, we must re-earn the decode notation from scratch, since the summary only sketched it.

Forecast: 4 KB $=0x1000$ bytes, so the next block starts one past ...0FFF.

1. Choose interval convention. We describe each window as the half-open interval $[\text{start},\text{start}+\text{size})$ — start inclusive, end exclusive. So a 4 KB block at 0x4000_0000 is $[0x4000\_0000,0x4000\_1000)$, meaning its last valid byte is 0x4000_0FFF. Why this step? Half-open intervals kill off-by-one bugs: the next block starts exactly at the previous block's end value, with no overlap and no gap-of-one. Inclusive/inclusive would force awkward $-1$ everywhere.
2. Size in hex. 4 KB $=2^{12}=0x1000$; 64 KB $=2^{16}=0x1\_0000$. Why this step? Sizes must be powers of two so the bit-slice decode of step 5 is a clean prefix compare.
3. Lay out the two 4 KB blocks. UART: $[0x4000\_0000,0x4000\_1000)$ → last byte 0x4000_0FFF. GPIO starts at the previous end value: $[0x4000\_1000,0x4000\_2000)$ → last byte 0x4000_1FFF. Why this step? Each start = previous half-open end; both starts are 4 KB-aligned (low 12 bits zero), so they decode cleanly.
4. Place the 64 KB DMA block with the natural-alignment rule. A block of size $S$ must start at a multiple of $S$ so its start and end share the same high bits (one prefix compare selects it). For DMA, $S=0x1\_0000$, so base mod 0x10000 == 0. The next free byte after GPIO is 0x4000_2000, but $0x4000\_2000\mathrm{mod}0x1\_0000=0x2000\ne 0$ — not aligned. Round up to the next multiple: 0x4001_0000 (since $0x40010000\mathrm{mod}0x10000=0$). DMA occupies $[0x4001\_0000,0x4002\_0000)$ → last byte 0x4001_FFFF. Why this step? Placing DMA at 0x4000_2000 would make its 64 KB span cross a $0x1\_0000$ boundary, so a single prefix compare could no longer isolate it. The rounding creates a deliberate unused gap 0x4000_2000–0x4000_FFFF — normal and cheap.
5. Decode UART. Route to UART iff address[31:12] == 0x40000. Why this step? Dropping the low 12 bits (the in-window offset) leaves the unique 20-bit page tag = the UART base.
6. Boundary tests (half-open in action). 0x4000_0FFF >> 12 = 0x40000 → UART ✓ (it is the last byte of UART's half-open interval). 0x4000_1000 >> 12 = 0x40001 → not UART; it is GPIO's start (included in GPIO, excluded from UART). Why this step? This is the classic off-by-one: the boundary address 0x4000_1000 belongs to GPIO precisely because UART's interval is half-open and excludes its own end.

Verify: UART span $=0x1000=4096$ bytes ✓. No overlap, no gap-of-one: UART end value 0x4000_1000 = GPIO start ✓. DMA base 0x40010000 is a multiple of 0x10000 (aligned) ✓ and its half-open interval $[0x40010000,0x40020000)$ does not touch GPIO's end 0x40002000. Routing: 0x40000FFF>>12=0x40000 (UART) but 0x40001000>>12=0x40001 (GPIO) — differ ✓. ✓

---

Example 8 — Real phone SoC word problem (cell J)

Forecast: don't blindly use $\min (6,4)$ — read the active count.

Figure caption — three competing caps. Three cyan bars: masters present ($6$), memory ports ($4$), masters active ($4$). An amber line marks the smallest — the binding limit ($4$). Concurrency is set by the shortest bar; here the active count ties the port count.

1. Pick the tool. Bandwidth question ⇒ crossbar formula $B_{\text{total}}=(\text{concurrent transfers})\times B$. Why this step? The word problem asks "how much data per second", exactly what the crossbar tool produces; MTBF and power tools answer different questions and do not apply.
2. Find concurrent transfers. Limited by three numbers — masters present (6), memory ports (4), masters actually active (4). The binding limit is $\min (4_{\text{active}},4_{\text{ports}})=4$. Why this step? Real workloads are capped by whichever is smallest; here active-master count ties the port count, both giving 4.
3. Compute. $B_{\text{total}}=4\times 12=48$ GB/s. Why this step? Multiply simultaneous transfers by per-link bandwidth to get the aggregate rate sustained.

Verify: $48$ GB/s $\le$ theoretical peak $\min (6,4)\times 12=48$ GB/s — this workload saturates the memory ports. Units GB/s. ✓ If only 2 masters were active, it would drop to $2\times 12=24$ GB/s.

---

Example 9 — Exam twist: bandwidth and power together (cell K)

Forecast: more links = faster; energy might tie because energy = work, not time.

Figure caption — power×time = area. Two rectangles on a power-vs-time plane: Option A is tall and thin (2 W for 3 s); Option B is short and wide (1 W for 6 s). Their areas are equal — both enclose $6$ J. The picture shows why the fast option does not automatically save energy: same enclosed area.

1. Transfer times. A: aggregate $4\times 8=32$ GB/s ⇒ $t_A=96/32=3$ s. B: $2\times 8=16$ GB/s ⇒ $t_B=96/16=6$ s. Why this step? Time = data ÷ bandwidth; this combines the crossbar tool (aggregate GB/s) with a rate divide (rate → duration).
2. Energy each. $E_A=(4\times 0.5\text{ W})\times 3\text{ s}=2\text{ W}\times 3=6$ J. $E_B=(2\times 0.5)\times 6=1\text{ W}\times 6=6$ J. Why this step? Energy = total power × time; count all active links since every link burns power simultaneously.
3. Conclude. Option A is twice as fast (3 s vs 6 s) but both use the same 6 J. Why this step? The twist is that speed and energy are different questions — the fast option saves no energy here because total work (bytes) and per-byte energy are equal. The tie-breaker is race-to-idle: A finishes 3 s earlier and can power-gate (Example 5), saving leakage B keeps paying.

Verify: $E_A=E_B=6$ J since work is fixed and per-byte energy equal. $t_A=3<t_B=6$. Race-to-idle: after finishing, A can gate and save leakage B still pays. ✓ Combines Network-on-Chip (NoC)-style bandwidth thinking with Power Management in SoCs.

---

Example 10 — Limiting behaviour sanity checks (cell L)

1. (a) $T_{\text{wait}}\to 0$. $e^{0/\tau }=e^0=1$, so $\text{MTBF}\to 1/(T_0{f}_{\text{clk}}{f}_{\text{data}})$ — the raw failure rate with no synchronizer. Meaning: zero wait = zero protection. Why this step? Confirms the exponential collapses to the unprotected baseline, as it must; a nonsense edge case would make us distrust the formula.
2. (b) $V\to 0$. $P_{\text{dyn}}=\alpha C{V}^{2}f\to 0$ quadratically. Meaning: at zero voltage the logic burns no dynamic power (and also does no work — the trade-off). Why this step? The $V^2$ tool must vanish at $V=0$; it does, and faster than linear, confirming the quadratic dependence.
3. (c) $N\to \infty$, $M$ fixed. $\min (M,N)\to M$. Meaning: past $N=M$, adding slaves buys nothing — bandwidth saturates at $M\times B$. Why this step? Shows the other clamp of $\min$: eventually the master side becomes the bottleneck, so both limbs of the formula behave.

Verify: (a) $e^0=1$ ✓. (b) ${\lim }_{V\to 0}{V}^2=0$ ✓. (c) for $N\ge M$, $\min (M,N)=M$ ✓. Every tool degrades sensibly at its boundary — no case left unshown.

---

Recall Self-test (reveal after trying)

Crossbar $M=5,N=2,B=10$: peak aggregate? ::: $\min (5,2)\times 10=20$ GB/s. Why does a 2-flop synchronizer fail on a 32-bit bus? ::: Each bit has a tiny nonzero skew probability $p$; word failure $\approx 32p$, small but never zero → certain over billions of transfers. Use handshake or async FIFO. DVFS drops $V$ by $20\%$ (frequency unchanged) — dynamic power ratio? ::: $(0.8{)}^2=0.64$, a $36\%$ cut. Power-gate a block idle $70\%$ of the time with $0.5$ W leakage, ignoring overhead — savings? ::: $0.7\times 0.5=0.35$ W. With address[31:12]==0x40000, does 0x4000_1000 reach UART? ::: No — it shifts to 0x40001; it belongs to GPIO (half-open interval excludes UART's end).

Related depth: AMBA Bus Standards, AXI Protocol, Physical Design Flow, Formal Verification Methods.