DMA controllers: Question bank — Hardware deep dive

This page is a stress-test for your mental model of DMA controllers. Every item below targets a specific misconception or boundary case. Cover the answer, commit to a reason (not just yes/no), then reveal.

Before the questions, a one-line refresher on the vocabulary we will reuse. If any of these is fuzzy, re-read the parent note first.

Recall Vocabulary you must have ready

SAR / DAR / BCR ::: Source Address, Destination Address, and Byte Count registers — where to read, where to write, how much is left.
Bus master ::: a device that can drive the address/data bus itself, not just respond. The DMA controller is one; so is the CPU.
Cycle stealing ::: DMA grabs the bus for one transfer, releases it, and asks again for the next.
Burst mode ::: DMA grabs the bus once and holds it for the whole block.

True or false — justify

Cover the answer. Say true/false and why.

DMA lets a peripheral transfer data with zero CPU involvement.

False — the CPU is not involved per byte, but it still programs SAR/DAR/BCR/CSR at the start and usually services the completion interrupt at the end. It is "hands-off during", not "hands-off entirely".

Burst mode always finishes a transfer faster than cycle stealing.

True for the DMA transfer's own wall-clock time, because it pays arbitration overhead once instead of per transfer — but it makes the whole system slower by locking the CPU out, so "faster" only holds for the block in isolation.

While DMA holds the bus in burst mode, the CPU is completely frozen.

Mostly false — the CPU can keep running any work that stays inside itself (register ALU ops, cache hits). It only stalls when it needs the external bus and finds it granted to DMA.

A DMA controller is a kind of CPU.

False — it has no instruction fetch/decode and runs no program. It is a fixed finite-state machine driven by its registers; it can only move bytes, not make decisions or branch on data.

Transparent mode gives you the highest guaranteed throughput of the three modes.

False — it gives the lowest CPU disturbance but the worst and least predictable throughput, since it only transfers in the gaps when the CPU isn't using the bus. A bus-hungry CPU can starve it.

Memory-to-memory (M2M) copies still benefit from DMA even though no peripheral is involved.

True — the win is that the CPU is freed from the per-byte load/store loop; the source and destination both being RAM does not change that the CPU would otherwise burn millions of instructions (Memory-Mapped IO aside, this is pure data shuffling).

Setting the EN bit is what starts the transfer, so the order you write the other registers doesn't matter.

True in the sense that SAR/DAR/BCR/CSR-mode bits are just latched values with no side effects until EN — but you must finish writing them before EN, or the state machine will launch with stale/garbage addresses.

Fixed-priority arbitration can never cause a device to wait forever.

False — that's exactly its weakness. A high-priority master that requests continuously can starve every lower-priority device indefinitely; rotating priority exists precisely to prevent this.

The Done bit and the interrupt line carry the same information, so having both is redundant.

False — the Done bit is a pulled status you poll; the interrupt is a pushed asynchronous signal. You need Done to let a handler confirm completion, and the interrupt (via Interrupts) to avoid busy-polling. They complement, not duplicate.

Spot the error

Each statement contains a mistake. Name it and give the correct version.

"For a 32-bit-wide transfer, the DMA increments SAR by 1 after each transfer."

Wrong step size — a 32-bit (word) transfer moves 4 bytes, so SAR increments by 4, not 1. The increment equals the transfer width in bytes, which is why the width field controls the address arithmetic.

"BCR counts up from 0 until it reaches the transfer size, then stops."

Backwards — BCR is loaded with the byte count and counts down; a hardware comparator triggers termination when BCR reaches 0. Counting down means the terminate condition is a single cheap "== 0" check.

"To copy 1 KB with a peripheral, set Direction = M2M."

Wrong direction code — a peripheral is involved, so it's P2M (peripheral-to-memory) or M2P, not M2M. M2M means both endpoints are ordinary memory addresses.

"Cycle stealing is faster than burst because it doesn't have to wait for the bus."

Exactly inverted — cycle stealing re-arbitrates for the bus on every single transfer, adding

T_{arb}

each time, so it is slower per block. Its advantage is CPU responsiveness, not speed.

"After DMA finishes, the CPU can immediately trust the data because the transfer went through the CPU's cache."

Wrong — DMA typically writes straight to memory, bypassing the CPU cache. The CPU may still hold stale cached copies, so the handler must invalidate/flush the cache. This is the Cache Coherency problem DMA creates.

"With a 256-transfer maximum burst length field (bits 8–15), you can transfer at most 256 bytes per burst."

Confuses transfers with bytes — 256 transfers at, say, word width is 256 × 4 = 1024 bytes. The burst length counts transactions, and each transaction moves width bytes.

Why questions

Give the reason, not just the fact.

Why does the DMA controller need a bus request/grant handshake at all?

Because it and the CPU are both bus masters wanting the same shared wires. Only one may drive the address/data bus at a time, so an arbiter must grant exclusive ownership before DMA drives anything — otherwise two drivers fight and corrupt the bus.

Why is burst mode "unfair" even though it's efficient?

Because it holds the bus for the entire block, so every other master — CPU, other DMA channels — is locked out for the whole duration. Efficiency for one transfer becomes starvation for everyone else.

Why can transparent mode achieve transfers with zero extra latency cost to the CPU?

Because it only moves data during cycles the CPU wasn't going to use the external bus anyway (cache hits, internal ops). It fills idle bus slots, so the CPU never notices the bus being "busy".

Why must each DMA register be writable by the CPU and readable/writable by the DMA logic?

The CPU writes them once to set up the transfer; the DMA logic then reads SAR/DAR to drive the bus and writes them back incremented/decremented each step. Both sides touch the same registers at different phases.

Why do fast devices like SSDs (3+ GB/s) make DMA essential rather than merely nice?

Without DMA the CPU would spend 100% of its cycles just executing the load/store copy loop at that rate, leaving nothing for actual programs. DMA moves the byte-shuffling off the instruction stream so the CPU can do real work concurrently.

Why does the transfer-width field simultaneously control the bus transaction size and the address increment?

Because they are the same physical quantity — a word transfer moves 4 bytes on the bus and advances the address pointer by 4. Decoupling them would let the controller skip or overlap bytes, which is nonsensical for a linear copy.

Why place the Done bit as read-only from the CPU's side?

Because Done reflects hardware state (BCR hit zero). If the CPU could write it arbitrarily, software could falsely claim a transfer finished — the status must be owned by the state machine that actually knows.

Edge cases

The boundaries where naive models break.

What happens if the CPU sets EN while BCR is already 0?

The comparator sees BCR = 0 immediately, so the state machine can transition straight to DONE without moving any bytes — a zero-length transfer. Good designs treat this as a completed no-op (and may still raise the completion interrupt if IE = 1).

What if the source and destination regions overlap in an M2M copy?

DMA does a straight incrementing copy with no overlap detection, so like a naive memcpy it can corrupt data when destination overlaps ahead of source. Overlap-safe moves are the caller's responsibility; the hardware won't protect you.

In cycle-stealing mode with a very bus-busy CPU, what limits DMA throughput?

The rate at which DMA can win arbitration between CPU cycles. If the CPU rarely yields the bus, DMA's grants come slowly, so throughput drops far below the transfer's raw capability — the same starvation transparent mode faces, but here the arbitration overhead is explicit.

What if the "increment SAR" bit is 0 (fixed address)?

SAR stays pinned to one address every transfer — correct for a peripheral FIFO where you always read the same data register (see UART or an SDRAM data port). Incrementing there would walk off into unrelated registers.

What happens to an in-flight burst if a higher-priority master requests the bus mid-transfer?

In pure burst mode, nothing — the burst is non-preemptible and the requester waits until the block completes. This is precisely why long bursts hurt latency; systems that need bounded latency either cap burst length or split into cycle-stealing chunks. Fabrics like ARM AMBA AXI and PCIe address this with bounded transaction sizes.

What if a DMA transfer targets a memory-mapped region that hasn't been mapped/enabled?

The bus access faults or reads garbage — DMA drives real bus transactions just like the CPU, so an unmapped or protected address produces the same error condition (bus error / abort). DMA does not get a special pass around the memory map.

Can two DMA channels run "simultaneously"?

Not on a single shared bus at the exact same cycle — only one may drive it. They interleave via arbitration, so they appear concurrent over time but physically take turns. True simultaneity needs independent bus segments or a multi-port fabric.

Recall One-line summary of the traps

Every trap here reduces to one of three truths: DMA is hands-off per byte, not entirely; DMA is a bus master that must share; and DMA bypasses the cache, so coherency is your job.