6.3.10 · D5Interconnects, Buses & SoC

Question bank — IP cores and SoC bus fabric

1,748 words8 min readBack to topic

This page is a misconception hunter. Each item below states a claim, an error, a "why", or a boundary case about the ideas in the parent note. Read the prompt, answer out loud before revealing, and — this is the whole point — make sure your reveal contains reasoning, not a bare "true" or "false".

Before we start, three words we will lean on. A master is an IP core that starts a transaction (a CPU asking for data). A slave is an IP core that responds (a RAM answering). Arbitration is the referee logic that picks one winner when several masters want the same slave at the same instant. Everything below assumes only these three ideas plus what the parent note built.


True or false — justify

A "soft" IP core is called soft because it is slower than hardware.
False — "soft" refers to malleability, not speed. It ships as synthesizable RTL (Verilog/VHDL) that you can reshape for any process node during synthesis, like clay; a hard core ships as a fixed physical layout you cannot reshape.
A hard IP core gives you the best flexibility to retarget process nodes.
False — it is the opposite. A hard core is a fixed GDSII layout optimised for one specific process, so it gives best performance/area but zero retargeting flexibility.
A bus fabric and a single shared bus are two names for the same thing.
False — a shared bus allows exactly one transaction at a time (one master owns the wires). A fabric is a switching network that supports multiple concurrent master→slave paths, arbitration per slave, and QoS.
AXI's five channels mean five separate physical buses running five unrelated transactions.
False — the five channels (AW, W, B, AR, R) are directions/phases of read and write, not five independent transaction streams. They let one transaction's address, data, and response phases overlap and pipeline.
In AXI, the master must finish sending all write data before it may issue the write address.
False — the Write Address (AW) and Write Data (W) channels are independent, so data can begin before, during, or after the address handshake. That decoupling is the entire reason for separate channels.
APB is non-pipelined, so it is strictly worse than AHB and should never be used.
False in intent — APB's minimal 2-cycle SETUP→ACCESS protocol is deliberately simple for low-speed peripherals (GPIO, timers, UART) where its tiny gate cost beats AHB's unneeded bandwidth.
A full crossbar's cost grows linearly with the number of ports.
False — for masters and slaves the crosspoint count is , a product. Doubling both roughly quadruples switches, which is why flat crossbars stop scaling past ~10–20 ports.
Adding more outstanding transactions on AXI always increases effective throughput without limit.
False — outstanding transactions hide latency only until the slave's real bandwidth (or buffer depth) saturates. Beyond that, more in-flight requests just queue; throughput plateaus at the slave's physical limit.
Arbitration is only needed when two masters target different slaves.
False — different slaves can be served in parallel with no conflict. Arbitration is needed precisely when two or more masters target the same slave, so one arbiter per slave port is required.
Burst transfers are faster because the slave runs at a higher clock.
False — a burst reuses one address handshake for many data beats, amortising the address overhead. The clock is unchanged; the win is fewer address cycles per byte moved.

Spot the error

"We used a shared bus, so the CPU reading RAM and the GPU reading a peripheral run at the same time."
Error: a shared bus serialises all traffic — only one master owns the bus per transaction. Those two accesses cannot overlap; you would need a multi-layer/crossbar fabric for that parallelism.
"AXI write response (B channel) is optional overhead we can drop to save a channel."
Error: the B response is how the master learns the write actually committed and whether it errored (BRESP). Dropping it means the master can never confirm completion — silent data loss on faults.
"For 4 masters and 8 slaves we need 4 arbiters, one per master."
Error: arbiters live at slaves, not masters, because contention happens when many masters hit one slave. You need arbiters, plus 8 address comparators, plus crosspoints.
"A firm IP core is delivered as physical layout, so it's fully optimised."
Error: firm IP ships as a gate-level netlist, a middle ground still allowing some technology mapping. Physical-layout (GDSII) delivery is the definition of a hard core.
"APB throughput at 32-bit, 100 MHz is 400 MB/s because it moves 32 bits per cycle."
Error: APB spends 2 cycles per transfer (SETUP + ACCESS), so it moves 32 bits per 2 cycles = 200 MB/s. The 400 MB/s figure is AHB's single-cycle pipelined rate.
"Since AXI supports out-of-order completion, the read data always returns in address order."
Error: out-of-order means responses may return in a different order than issued; transaction IDs tag which response belongs to which request. Assuming address order will mismatch the data.
"A DDR4 PHY is a soft IP core we can synthesise for any node."
Error: a DDR PHY has analog/mixed-signal timing-critical circuitry and is delivered as a hard core (fixed layout) for one process. It is not synthesisable RTL.

Why questions

Why does AXI split each transfer into separate address and data channels instead of one combined bus like AHB?
Because address and data phases have different timing and lifetimes; separating them lets the slave accept and decode an address while the master is still assembling data, enabling deep pipelining and overlap.
Why is one arbiter placed per slave rather than one global arbiter for the whole fabric?
Contention is local to each shared resource — a per-slave arbiter only resolves the masters aiming at that slave, allowing all other slave ports to proceed in parallel. A single global arbiter would needlessly serialise everything.
Why can't we just build one giant flat crossbar for a 100-IP SoC?
Cost scales as crosspoints plus wiring congestion, so a 100-port crossbar is enormous in area and unroutable. Hierarchical fabrics / Network-on-Chip break it into small local crossbars joined by routers.
Why does a burst transfer need a WLAST (last-beat) signal?
Because the address phase only stated a start and length; the slave still needs an explicit marker on the final data beat to know the burst is complete and to close the transaction and send its response.
Why do designers reuse verified IP cores instead of designing every block fresh?
Verification, not design, dominates SoC schedules; reusing a pre-verified core with a defined interface cuts development from years to months and frees the team to focus on their differentiating logic.
Why does AXI achieve higher effective throughput than its single-transaction number suggests?
Because multiple transactions can be in-flight simultaneously; while one waits on slave latency, others make progress, so latency is hidden and the pipeline stays full — until the slave's raw bandwidth caps it.

Edge cases

What happens on a crossbar if a master addresses a region that maps to no slave?
The address decoder finds no matching slave range and must return a decode/error response (e.g. an AXI DECERR) rather than hang; a fabric without a default error target would deadlock the master waiting for a response.
Two masters request the same slave in the exact same cycle — what breaks, and what saves it?
Nothing breaks if the slave's arbiter picks one winner and makes the other wait; without arbitration both would drive the slave simultaneously (bus contention / corruption). The arbiter's whole job is this tie.
A burst is issued but the master's WVALID never asserts for the last beat — what is the state?
The transaction stalls indefinitely: the slave has seen the address but is missing the final data beat with WLAST, so it cannot complete or issue a B response. This is a classic hang debugged via the pending-outstanding count.
If (single master) and slaves, do we still need arbiters?
No — with only one master no slave can ever be contended, so the arbiters collapse to trivial pass-throughs. You still need address comparators to route to the right slave.
A slave has only one buffer slot but a master issues 4 outstanding reads to it — what happens to throughput?
The slave can hold only one request, so the extra three queue at the master/fabric and gain nothing; effective throughput drops to the single-outstanding case. Outstanding depth is only useful up to the slave's buffering.
At what point does a shared bus's throughput advantage over a crossbar appear?
When traffic is genuinely low and mostly serial (a tiny microcontroller), the shared bus wins on area and cost — its lack of parallelism is irrelevant if transactions never overlap, and it avoids the crossbar's hardware.
Recall One-line self-test

Where does arbitration live, and why there? ::: At each slave port, because contention only occurs when multiple masters target the same slave — a per-slave referee lets all other slaves run in parallel.

Connected reading