6.3.9 · D2Interconnects, Buses & SoC

Visual walkthrough — System-on-Chip (SoC) integration

1,934 words9 min readBack to topic

This page rebuilds the single most-used number in System-on-Chip (SoC) integration: the peak bandwidth of a crossbar interconnect,

The parent note stated this. Here we earn it — one picture at a time. By the end you will know exactly what every symbol means, why the formula uses min and not plus or times, and what happens in every awkward case (one master, one slave, everyone fighting for the same memory).


WHAT. Before any formula, we name every piece and give it a picture. A master is a block that starts a data transfer (it says "read address X" or "write this"). A slave is a block that responds (memory, a peripheral). A link is one physical set of wires that can carry data.

WHY. You cannot count trucks until you know how many roads exist and who is allowed on them. Every symbol below is defined on this one drawing so nothing is a mystery later.

PICTURE. On the left, masters (blue). On the right, slaves (pink). Every master has one link out; every slave has one link in.

Figure — System-on-Chip (SoC) integration

Step 2 — What is a "crossbar"? Full connectivity

WHAT. A crossbar is an interconnect where every master can reach every slave, and many pairs can talk at the same time. Imagine a grid of streets: horizontal wires (one per master) crossing vertical wires (one per slave), with a switch at each intersection.

WHY use a crossbar and not a single shared bus? A shared bus is one road everybody queues on — only one transfer at a time. A crossbar is the opposite extreme: build a switch at every crossing so independent conversations never block each other. We pay area for that (more on cost in Step 8), but we buy parallelism.

PICTURE. The grid below. A filled dot at row , column means "master is currently connected to slave ." Notice each row can have at most one dot lit, and each column can have at most one dot lit — that constraint is the whole derivation.

Figure — System-on-Chip (SoC) integration

Step 3 — Count trucks in the best case (fewer masters than slaves)

WHAT. Suppose (more destinations than senders). Ask: what is the largest number of simultaneous transfers? Since each master has exactly one link and they all pick different slaves, every master gets to move at once.

WHY. We want the peak — the ceiling performance the fabric can ever hit. So we assume the friendliest traffic: no two masters want the same slave. There is nothing to fight over.

PICTURE. Four masters, but here : each blue arrow lands on its own pink slave. Count the green (active) arrows.

Figure — System-on-Chip (SoC) integration

Every master is busy, each contributing , so we simply add them up: copies of .


Step 4 — The other side: fewer slaves than masters

WHAT. Now flip it: (more senders than destinations). Even in the friendliest traffic, you cannot light more than dots, because there are only columns (slaves), and each column holds one dot.

WHY. The slaves are now the bottleneck. Extra masters simply have nobody free to talk to — some must wait. The parallelism is capped by whichever side is smaller.

PICTURE. Five masters, three slaves. Only three arrows can be green at once; two masters (greyed) stall.

Figure — System-on-Chip (SoC) integration


Step 5 — Fuse the two cases with min

WHAT. Step 3 gave when ; Step 4 gave when . Both say the same thing: the number of simultaneous transfers equals the smaller of and . The word "smaller" is exactly what means.

WHY min and not + or \times?

  • Not $M+B$ — we are counting how many links run at once ( or ), then each carries . Bandwidths of parallel links add, giving a product with , not a sum with .
  • Not $M\times N \times B$ — that would need every master talking to every slave simultaneously, but one master has one link. Impossible.
  • $\min$ picks the true limiter: the narrower side of the funnel.

PICTURE. A funnel view — pipes on the left, pipes on the right; the throughput is throttled by the narrow end.

Figure — System-on-Chip (SoC) integration

Since when and otherwise, this one line reproduces both earlier cases at once.


Step 6 — The worst case: everyone wants the same slave

WHAT. Peak assumed different destinations. Now the nastiest traffic: all masters target slave 0. That column can hold only one dot, so transfers must happen one after another (serialized). Peak collapses to a single link.

WHY show this? Because "peak" is a promise the fabric rarely keeps. Real programs have hotspots (everything reads DRAM). A designer must know both the ceiling and the floor.

PICTURE. All masters aim at slave 0. Only one green arrow at a time; the rest queue. An arbiter (the yellow referee) decides whose turn it is.

Figure — System-on-Chip (SoC) integration


Step 7 — Degenerate cases (never leave a scenario unshown)

WHAT. Plug tiny numbers into and check nothing breaks.

Case Meaning
Single master, single slave 1 1 A crossbar degenerates to one wire — no parallelism possible.
One master, many slaves 1 8 One sender can only use one link at a time, so extra slaves don't help its bandwidth.
Many masters, one slave 8 1 Same as the worst case — the lone slave is the funnel.
Zero masters 0 5 Nobody sends → no traffic. Formula gives , correct.

WHY. A formula you trust must survive its edges. Notice handles all of them gracefully: whenever either side is 1 (or 0), bandwidth is (or 0). No special-casing needed.

PICTURE. The four degenerate wirings side by side.

Figure — System-on-Chip (SoC) integration

Step 8 — The cost we paid, and worked numbers

WHAT. The crossbar's parallelism is not free. A full switch grid has an intersection for every (master, slave) pair, so the area (and power) grows like . That is why the parent note said "cost grows as " and why huge chips switch to a Network-on-Chip instead.

WHY contrast bandwidth () with cost ()? The tension is the whole design decision: you gain bandwidth but pay silicon. Doubling both sides doubles peak bandwidth but quadruples area.

Worked example (the parent's numbers, now fully derived): (CPU, GPU, DMA, DSP), (DRAM, Flash, peripherals), GB/s.

  • Peak: GB/s (three different slaves busy at once; the 4th master waits).
  • Worst: all hit DRAM GB/s.
  • Switch cost: crossing points.

PICTURE. Bandwidth (green, follows ) vs. area cost (yellow, follows ) as the chip scales from up to . Watch the yellow curve leave the green one behind.

Figure — System-on-Chip (SoC) integration

The one-picture summary

Everything above, compressed: the funnel gives parallel links, each worth ; friendly traffic hits the ceiling, one-hot-slave traffic hits the floor ; and the silicon bill grows as .

Figure — System-on-Chip (SoC) integration
Recall Feynman retelling — say it back in plain words

A crossbar is a switchboard: senders on one side, receivers on the other, and any sender can be patched to any receiver. But each sender has only one plug and each receiver has only one socket. So the number of simultaneous calls can never beat the smaller group — that's the . Multiply by how much one line carries, , and you have the best-ever bandwidth . If everyone dials the same receiver, they queue and you're back to a single line's worth, . The catch: building "any-to-any" needs a switch at every crossing, so the hardware bill scales as — grow the chip and cost balloons faster than speed, which is why very large chips ditch the crossbar for a packet-switched network on chip.

Recall

What does the min in physically mean? ::: The maximum number of transfers that can run at once is limited by the smaller side — you can't have more parallel conversations than there are masters, nor more than there are slaves. Why is it and not ? ::: Each parallel link independently carries GB/s; parallel bandwidths add up, so links give where . Best case vs worst case for ? ::: Best GB/s (three different slaves), worst GB/s (all target one slave). Why do big SoCs abandon the crossbar? ::: Switch area/power grows as , so cost explodes far faster than the bandwidth gain.

Related vault topics: AXI Protocol · AMBA Bus Standards · Network-on-Chip (NoC) · Clock Domain Crossing Techniques · Power Management in SoCs · Physical Design Flow · Formal Verification Methods