Visual walkthrough — DMA controllers

This page answers one very concrete question, from absolute zero:

When a DMA controller moves $N$ chunks of data, how long does it take — and how much of that time does it steal from the CPU?

The parent note (DMA controllers) gave you the two headline formulas for burst and cycle-stealing modes. Here we build those formulas from a blank timeline, one clock tick at a time, so you can see exactly where every number comes from.

We assume nothing. If you have never seen a "bus", a "clock cycle", or the symbol $N$, you will by the end.

---

Step 1 — What a "clock cycle" is, and why we measure time in them

WHAT. A digital chip has a clock: a signal that ticks up-down-up-down forever, like a metronome. One full tick is called a clock cycle. Everything the hardware does — reading a byte, adding to an address — happens on these ticks.

WHY. We cannot measure hardware time in seconds directly, because the same design might run at different speeds. Instead we count cycles (a pure count, no units), then convert to seconds at the very end using the clock's frequency. This separates "how many steps" from "how fast each step is".

PICTURE. Below, each little box is one cycle. The clock frequency $f$ (ticks per second) sets how long a single cycle lasts in seconds. Call that duration $t_{\text{sec}}$:

$\underset{\text{seconds in ONE cycle}}{\underbrace{t_{\text{sec}}}}=\frac{1}{\underset{\text{ticks per second}}{\underbrace{f}}}$

So at $f=100\text{ MHz}=100,000,000$ ticks/second, one cycle lasts $t_{\text{sec}}=\frac{1}{100000000}\text{s}=10\text{ns}$.

Two different things, do not confuse them: $t_{\text{sec}}$ is seconds per one cycle (a conversion factor, units: seconds). Later, $T_{\text{cycle}}$ will be how many cycles one data transfer takes (a count, units: cycles). To get real time we multiply: $\text{(cycle count)}\times t_{\text{sec}}=\text{seconds}$.

Prerequisite plumbing lives in Bus Architecture — the shared wires that data travels on.

---

Step 2 — What the DMA is actually moving: $N$ transfers of a fixed width

WHAT. The data to move is a block of bytes — say $B$ bytes total. But the bus doesn't move one byte at a time; it moves a fixed width $w$ of bytes at once (1, 2, or 4 bytes, chosen by the width bits in the control register). Each width-sized gulp is called one transfer.

WHY. A 32-bit-wide bus carries 4 bytes in the same single cycle it would carry 1 byte — the wires are already there. So we count transfers, not bytes. The number of transfers is:

$N=\frac{\stackrel{\text{total bytes}}{\overbrace{B}}}{\underset{\text{bytes per transfer}}{\underbrace{w}}}$

PICTURE. Cutting a $B=4096$-byte block into $w=4$-byte pieces gives $N=1024$ pieces. Each piece is one trip across the bus.

---

Step 3 — The cost of ONE transfer: read, then write

WHAT. A memory-to-memory DMA transfer is really two bus actions: read the source, write the destination. On a back-to-back optimized bus these overlap into roughly one bus cycle of steady-state throughput once the pipeline is full. We call this steady per-transfer time $T_{\text{cycle}}$ — the number of cycles one already-warmed-up transfer consumes.

WHY. We need one honest number for "how long does the machine spend on one gulp of data, once it's warmed up?" Everything else is overhead layered on top of this. Isolating it lets us reason about the two modes separately.

PICTURE. The read puts the source address (Memory-Mapped IO-style) on the wires, grabs the data; the write puts the destination address and pushes the data out. Steady-state, each new transfer completes every $T_{\text{cycle}}\approx 1$ cycle.

---

Step 4 — The overhead the DMA cannot skip: arbitration

WHAT. The DMA controller does not own the bus. To use it, it must ask: it asserts a "bus request" wire and waits for the arbiter to answer with a "grant". This request→grant handshake costs a few cycles and does no data movement. Call it $T_{\text{arb}}$ (arbitration).

How $T_{\text{arb}}$ relates to $T_{\text{setup}}$: In burst mode we pay one bigger startup block called $T_{\text{setup}}$, which is the arbitration plus placing the very first address on the bus: roughly $T_{\text{setup}}=T_{\text{arb}}+(\text{first-address setup})$. So $T_{\text{setup}}$ is slightly larger than $T_{\text{arb}}$ (in our example $T_{\text{setup}}=4$ cycles versus $T_{\text{arb}}=3$ cycles). The key point: $T_{\text{setup}}$ is paid once, whereas $T_{\text{arb}}$ is paid per transfer.

WHY. The bus is shared between the CPU and every DMA channel (see ARM AMBA AXI arbiters). Somebody must decide who drives the wires each cycle, or two devices would fight and corrupt the data. That decision is not free.

PICTURE. Grey "wasted" cycles are arbitration; coloured cycles are real data. The whole game of choosing a transfer mode is: how often do we pay this grey tax?

---

Step 5 — Burst mode: pay the tax ONCE

WHAT. In burst mode the DMA asks for the bus one time, then holds it and fires all $N$ transfers back-to-back before releasing. Total time (in cycles):

$T_{\text{burst}}=\underset{\text{arb + first address, paid once}}{\underbrace{T_{\text{setup}}}}+\underset{\text{transfers}}{\underbrace{N}}\times \underset{\text{cycles per transfer}}{\underbrace{T_{\text{cycle}}}}$

WHY. Because we ask only once, the setup cost is amortized — spread thin across all $N$ transfers. This is the fastest possible mode: pure data movement with a single tiny prefix.

PICTURE. One short grey block up front, then a long unbroken rainbow of data cycles.

---

Step 6 — Cycle-stealing mode: pay the tax EVERY time

WHAT. In cycle-stealing mode the DMA asks, does one transfer, releases the bus, then asks again for the next. Every one of the $N$ transfers now carries its own arbitration cost $T_{\text{arb}}$ plus the same per-transfer data cost $T_{\text{cycle}}$ we defined in Step 3:

$T_{\text{cycle-steal}}=N\times (\underset{\text{ask, paid every time}}{\underbrace{T_{\text{arb}}}}+\underset{\text{one gulp of data (same symbol as Step 3)}}{\underbrace{T_{\text{cycle}}}})$

WHY. By releasing the bus between transfers, the DMA lets the CPU sneak in and stay responsive (Interrupts-driven work doesn't stall). The price is that the grey tax is no longer amortized — it multiplies by $N$.

PICTURE. Grey-colour-grey-colour, alternating forever. The CPU can grab a turn in the gaps.

---

Step 7 — Edge & degenerate cases (never leave a gap)

WHAT. Let's stress-test the two formulas at their extremes. First a name: the Byte Count Register (BCR) is the hardware counter inside the DMA that holds how many bytes remain to move; the controller decrements it after each transfer and stops when it hits zero. So "$N=0$" means "BCR started at zero — nothing queued".

CASE $N=0$ (nothing to move). The BCR starts at $0$.

• Burst: the formula gives $T=T_{\text{setup}}+0\times T_{\text{cycle}}=T_{\text{setup}}$. But a real controller inspects $\text{BCR}=0$ before it bothers to arbitrate, and short-circuits straight to "done", so in practice $T=0$. The formula and the optimization agree once you read the formula as "cost given that we entered the transfer state machine"; the BCR=0 pre-check simply means we never enter it, so $T_{\text{setup}}$ is never spent. No contradiction — the formula describes work done, the pre-check avoids doing any.
• Cycle-steal: $T=0\times (T_{\text{arb}}+T_{\text{cycle}})=0$. Consistent — no transfers, no cost.

CASE $N=1$ (a single transfer). The two modes converge: $T_{\text{burst}}=T_{\text{setup}}+T_{\text{cycle}},T_{\text{cycle-steal}}=T_{\text{arb}}+T_{\text{cycle}}$ With $T_{\text{setup}}\approx T_{\text{arb}}$, burst's amortization advantage vanishes — you can't spread a one-time cost over one item.

CASE $N\to \infty$ (huge transfer). The setup term becomes negligible against $N$: $\frac{T_{\text{burst}}}{N}\stackrel{N\to \infty }{\to }{T}_{\text{cycle}},\frac{T_{\text{cycle-steal}}}{N}\stackrel{N\to \infty }{\to }{T}_{\text{arb}}+T_{\text{cycle}}$ So for big blocks the per-transfer cost — the slope of the timeline — is all that matters, and burst wins by the fixed ratio $\frac{T_{\text{arb}}+T_{\text{cycle}}}{T_{\text{cycle}}}$.

PICTURE. Two lines: time versus $N$. Both are straight; they cross near $N=1$ and fan apart. The slope is the per-transfer cost; the y-intercept is the setup tax.

---

The one-picture summary

Everything above collapses into a single timeline comparison: the same $N$ transfers, drawn twice — burst (one tax, then a clean run) versus cycle-stealing (a tax before every gulp). The area of grey is the wasted time; the coloured area is identical in both.

$\boxed{T_{\text{burst}}=T_{\text{setup}}+N{T}_{\text{cycle}}{T}_{\text{cycle-steal}}=N(T_{\text{arb}}+T_{\text{cycle}})}$

Recall Feynman retelling — explain it to a friend

The DMA is a courier moving $N$ parcels across a shared hallway (the bus). Before entering the hallway it must ask the guard for permission — that "asking" wastes a few seconds and moves no parcels.

In burst mode the courier asks once, then sprints all $N$ parcels through without stopping. The asking-cost ($T_{\text{setup}}$) is paid a single time, so with many parcels it's basically free per parcel. But the whole hallway is blocked while the courier runs — nobody else (the CPU) can pass.

In cycle-stealing mode the courier is polite: ask, carry one parcel, leave, ask again, carry the next. The CPU can slip through between trips, so everyone stays responsive — but now the "asking" ($T_{\text{arb}}$) happens $N$ times, and that adds up to about four times longer for our example numbers.

The math is just: time = (one-time asking) + (number of parcels × time per parcel) for burst, versus (number of parcels × (asking + carrying)) for cycle-stealing, where "carrying one parcel" is the same $T_{\text{cycle}}$ in both. When there are zero parcels (BCR started at 0), both cost nothing. When there's one parcel, they're the same. When there are thousands, the slope (per-parcel cost) is everything, and burst's shallower slope wins — at the price of blocking the hallway. The whole engineering choice is: how often do you pay the guard?

Related coherence concerns when DMA writes memory the CPU has cached: see Cache Coherency.