Case Study: DMA Master on AHB

The third case study turns the single-master picture into a real multi-master system by adding a DMA engine as a second AHB master. A DMA (Direct Memory Access) engine moves blocks of data — say, from memory to a peripheral, or between memory regions — without the CPU doing the copying. This is where the arbitration and handover from the multi-master module appear in a real system. The DMA is a full AHB master, structurally identical to the CPU: it asserts HBUSREQ when it wants the bus, the arbiter grants it (HGRANT one cycle ahead) and switches HMASTER to the DMA only at a transfer boundary (never mid-burst), the DMA runs bursts to move the block efficiently, then releases the bus and the arbiter hands it back to the CPU. The benefit: the CPU is offloaded from bulk copying — it sets up the DMA, then keeps working on other code, overlapping with the DMA, stalling only when it itself needs the bus the DMA currently holds. This chapter traces the request → grant → boundary handover → burst → hand-back flow — the multi-master protocol in action.

1. What Is It?

This case study shows a DMA engine as a second AHB master — arbitration and handover in a real system. The flow:

• The DMA is a full AHB master — structurally identical to the CPU. It drives the bus (address phase, bursts) when it owns it.
• Request + grant — the DMA asserts HBUSREQ when it wants the bus; the arbiter grants it (HGRANT, one cycle ahead).
• Boundary handover — the arbiter switches HMASTER to the DMA only at a transfer boundary (HREADY high, CPU not mid-burst). Then the DMA drives.
• Burst + hand-back — the DMA runs bursts (NONSEQ then SEQ) to move the block efficiently; when done, it releases the bus and the arbiter hands it back to the CPU.

So this case study shows the multi-master protocol in a real, motivated scenario — a DMA offloading the CPU. The value of tracing it is seeing why multi-master exists (to let two agents share one bus productively — the CPU computing while the DMA copies) and how the arbitration mechanism (HBUSREQ/HGRANT/HMASTER, boundary handover) manages the sharing. The DMA makes the abstract arbitration concepts concrete: a real second master, with a real job (bulk data movement), contending for the real bus. So this case study is the multi-master path. So it shows arbitration and handover in action.

2. Why Does It Exist?

This case study exists because DMA is the canonical reason for multi-master AHB (it's the most common second master in real systems) — so it motivates arbitration concretely (you see why you'd want two masters) — and because it demonstrates the arbitration mechanism end-to-end (request, grant, boundary handover, burst, hand-back) in a real scenario.

The DMA is the canonical second master is the root: most AHB systems are single-master (just a CPU) until you add a DMA — the most common reason to go multi-master. So DMA is the canonical second master. So understanding it motivates multi-master. So this case study exists to ground multi-master in its most common form. So DMA is why multi-master exists. So trace it.

The it motivates arbitration concretely is the value: the abstract arbitration concepts (request/grant/handover) can seem academic — until you see a real DMA needing the bus while the CPU also wants it. So this case study motivates arbitration — you see why it's needed (two productive agents sharing one bus). So it exists to make arbitration concrete. So it's the motivation. So see the contention.

The it demonstrates the mechanism end-to-end is the demo: the DMA exercises the whole arbitration mechanism — request (HBUSREQ), grant (HGRANT), boundary handover (HMASTER), burst, hand-back. So this case study demonstrates the full flow in one scenario. So it exists to show the mechanism in action. So it's the end-to-end demo. So watch the handover. So this case study exists because: DMA is the canonical second master (the root); it motivates arbitration concretely (you see why two masters — the value); and it demonstrates the mechanism end-to-end (request → grant → handover → burst → hand-back — the demo). So the DMA-master case study is the multi-master path — grounding arbitration in its most common, motivated form. So this chapter shows multi-master in action. So trace the DMA, and watch the handover.

3. Mental Model

Model the DMA-as-second-master as a household with one car shared between you and a courier you hired to run errands. Normally you (the CPU) drive. When you have a big delivery to make — moving a load of boxes across town (a block of data) — instead of doing it yourself, you dispatch the courier (the DMA): you tell them the pickup, the drop-off, and how many boxes (program source, destination, length). The courier waits for the car to be free (asserts HBUSREQ, waits for grant), and crucially takes the keys only when you've parked and finished your current trip — never grabbing the wheel mid-drive (handover only at a transfer boundary). Then the courier drives the whole load across efficiently in one trip (a burst), and hands the keys back when done. Meanwhile, you got on with other things (the CPU keeps computing) — you only wait if you need the car while the courier has it. One car, two drivers, a dispatcher deciding who drives — that's a DMA on a shared bus.

A one-car household shared between you (the CPU) and a courier you hired (the DMA). Normally you drive (the CPU is the default master). When you have a big delivery — moving a load of boxes across town (a block of data) — instead of doing it yourself (the CPU copying byte by byte), you dispatch the courier (the DMA): you tell them the pickup, drop-off, and how many boxes (program the DMA — source, destination, length). The courier waits for the car to be free (asserts HBUSREQ, waits for HGRANT), and crucially takes the keys only when you've parked and finished your current trip — never grabbing the wheel mid-drive (handover only at a transfer boundary, never mid-burst). Then the courier drives the whole load across efficiently in one trip (a burst), and hands the keys back when done (releases the bus). Meanwhile, you got on with other things (the CPU keeps computing) — you only wait if you need the car while the courier has it (the CPU stalls only when it needs the bus the DMA holds). One car, two drivers, a dispatcher deciding who drives (the arbiter) — that's a DMA on a shared bus.

This captures the DMA path: you normally driving = the CPU as the default master; dispatching the courier for a big delivery = offloading bulk copy to the DMA; telling them pickup/drop-off/count = programming the DMA (source, destination, length); the courier waiting for the car = the DMA asserting HBUSREQ and waiting for the grant; taking the keys only when you've parked = handover only at a transfer boundary (never mid-burst); driving the load across in one efficient trip = the DMA running a burst; handing the keys back = releasing the bus; you getting on with other things = the CPU overlapping its own work; the dispatcher deciding who drives = the arbiter. Dispatch the courier (program the DMA), wait for the car (request/grant), take the keys at a clean stop (boundary handover), drive the load (burst), hand back — and you got other things done meanwhile.

Here is the handover and burst, traced:

The model's lesson: dispatch the courier (program the DMA), wait for the car (request/grant), take the keys at a clean stop (boundary handover), drive the load (burst), hand back. In the figure, the DMA requests, the arbiter grants one cycle ahead, HMASTER switches at the boundary (never mid-burst), and the DMA runs its burst — the standard mechanism, with a real second master doing a real job.

4. Real Hardware Perspective

The substance behind the trace is the multi-master structure from Module 5 — so each step maps to a chapter, applied to the DMA.

The request, grant, and handover: in hardware — the DMA asserts HBUSREQ; the arbiter asserts HGRANT (one cycle ahead); HMASTER switches at a boundary. So the trace applies the arbitration structure (see Why Arbitration, HBUSREQ / HGRANT, HMASTER, Bus Ownership Handover). So it's the sharing mechanism. So request, grant, hand over at a boundary.

The the burst and the offload: in hardware — the DMA runs bursts (NONSEQ/SEQ, incrementing) for efficient bulk movement; the benefit is the CPU offloaded (it overlaps its own work). So the trace applies the burst and multi-master structure (see Single vs Burst Transfer, HBURST, Multiple Masters). So in practice, the DMA path is the multi-master protocol applied — request, grant, boundary handover, burst, hand-back — with a real second master offloading the CPU. So in practice, know the multi-master structure and trace it on the DMA. So that's the multi-master path.

5. System Architecture Perspective

At the system level, the DMA reveals why multi-master matters — it parallelizes the system (the CPU computes while the DMA copies), improving throughput — and it introduces the arbitration design space (the policy, covered in the arbitration subject, now concrete: CPU vs DMA priority, fairness, real-time).

The multi-master parallelizes the system: with one master, the CPU does everything — including bulk copying (slow, wasteful). With a DMA as a second master, the CPU offloads copying and computes in parallel. So the system parallelizes — more work per unit time. So at the system level, the DMA improves throughput. So offload the CPU. So it's the parallelism win.

The it makes the arbitration design space concrete: with two masters, you must decide the policy — does the CPU or the DMA get priority? A real-time DMA (feeding a display) might need a guaranteed bandwidth share; a background DMA might be low priority. So the DMA makes the arbitration design space (covered in the arbitration subject) concrete — a real policy decision. So at the system level, the DMA introduces the arbitration tradeoffs. So choose the policy. So it's the design decision. So at the system level, the DMA parallelizes the system (CPU computes while DMA copies — improving throughput) and makes the arbitration design space concrete (the CPU-vs-DMA policy decision). So the DMA is where multi-master pays off — making the offload (parallelism) and the arbitration policy (the design decision) the keys to a productive multi-master system. So offload the CPU, and choose the policy. So the DMA is the multi-master win.

6. Engineering Tradeoffs

Tracing the DMA path surfaces the multi-master design points.

• DMA offload vs CPU copy. A DMA offloads bulk copying (CPU computes in parallel); CPU copying wastes CPU cycles. Use a DMA for bulk movement.
• Boundary handover vs mid-burst switch. Ownership transfers only at a boundary (never mid-burst) — so a DMA burst is never split. This is correctness.
• Arbitration policy (CPU vs DMA priority). Who gets priority is a design decision (covered in the arbitration subject): a real-time DMA may need a bandwidth guarantee; a background DMA may be low priority.
• Bus contention vs overlap. The CPU and DMA share one bus — when both want it, one waits. The win is the overlap (CPU computing while DMA copies); the cost is contention when both need the bus.

The throughline: the DMA is a second AHB master — it asserts HBUSREQ, the arbiter grants it (HGRANT one cycle ahead) and switches HMASTER at a boundary (never mid-burst), the DMA runs bursts to move a block, then hands back. The DMA is a full AHB master (same mechanism as the CPU). The benefit: the CPU is offloaded and overlaps its own work. At the system level, the DMA parallelizes the system (throughput) and makes the arbitration design space concrete (the CPU-vs-DMA policy).

7. Industry Example

A concrete trace — a DMA moving a buffer to a peripheral while the CPU computes.

A system needs to send a block of data out a peripheral (say, a buffer to a communication peripheral). Instead of the CPU copying it word by word, a DMA engine does it.

• The CPU programs the DMA. The CPU writes the DMA's control registers: source address (the buffer in memory), destination (the peripheral's data register), and length. Then it starts the DMA and returns to its own code.
• The DMA requests the bus. Ready to move the first chunk, the DMA asserts HBUSREQ. The CPU currently owns the bus (running its code), so the DMA waits.
• The arbiter grants the DMA. The arbiter, by its policy, asserts the DMA's HGRANT — one cycle ahead. It waits for the CPU's current transfer (or burst) to finish.
• Handover at the boundary. At the next transfer boundary — HREADY high, CPU not mid-burst — the arbiter switches HMASTER to the DMA. The DMA now owns the bus.
• The DMA runs a burst. The DMA reads a block from the source with an incrementing burst (NONSEQ then SEQ), then writes it to the destination — moving the data efficiently, far faster than the CPU copying word by word.
• Hand-back and overlap. When the DMA finishes its transfer (or yields), it deasserts HBUSREQ, and the arbiter hands the bus back to the CPU. Throughout, the CPU was computing in parallel — it only stalled if it needed the bus while the DMA held it. When the whole block is done, the DMA raises a completion interrupt, and the CPU handles the next step.
• The win. The CPU spent its time computing, not copying — the DMA did the bulk movement in parallel. Two masters, one bus, the arbiter managing the sharing.

The example shows the multi-master protocol in action: the DMA requests, the arbiter grants and hands over at a boundary, the DMA bursts the data, and hands back — all while the CPU overlaps its own work. This is why multi-master exists, and how arbitration manages it.

8. Common Mistakes

9. Interview Insight

The DMA path shows multi-master in action — tracing it (request, grant, boundary handover, burst, hand-back) shows you understand arbitration and handover in a real system.

If asked to show how a DMA works on AHB, trace the multi-master flow: the DMA asserts HBUSREQ, the arbiter grants it (HGRANT one cycle ahead), HMASTER switches at a transfer boundary (never mid-burst), the DMA runs bursts to move the block, then hands the bus back. Stress that the DMA is a full AHB master (the same request/grant/handover mechanism as the CPU — nothing special about its bus interface), that ownership transfers only at a boundary (a burst is never split), and that the benefit is parallelism (the CPU computes while the DMA copies, overlapping). That shows you understand multi-master AHB in a real system — and sets up the arbitration policy discussion (CPU vs DMA priority, covered as its own subject).

10. Practice Challenge

Practice tracing the multi-master path.

1. The flow. Trace a DMA: program it, it asserts HBUSREQ, the arbiter grants (HGRANT ahead), HMASTER switches at a boundary, it bursts, it hands back.
2. The full-master point. Explain why the DMA is a full AHB master (same mechanism as the CPU) — nothing special about its interface.
3. The boundary. Explain why handover happens only at a boundary (never mid-burst) — atomicity and the single-driver rule.
4. The offload. Explain what the DMA buys you (parallelism + burst efficiency) over the CPU copying.
5. The policy. Note the arbitration policy decision (CPU vs DMA priority) that two masters force.

11. Key Takeaways

• A DMA is a second AHB master — it moves blocks (e.g. memory ↔ peripheral) so the CPU doesn't copy. Arbitration and handover in a real system.
• The DMA is a full AHB master — structurally identical to the CPU: same HBUSREQ/HGRANT/HMASTER request/grant/handover, same bursts. Its job is special, not its interface.
• The flow — the DMA asserts HBUSREQ, the arbiter grants (HGRANT one cycle ahead), HMASTER switches at a boundary, the DMA runs bursts, then hands back.
• Ownership transfers only at a boundary — never mid-burst (a DMA burst is never split); one master drives at a time.
• The benefit is parallelism — the CPU computes while the DMA copies, overlapping; the CPU stalls only on contention (both need the bus).
• Two masters force an arbitration policy — CPU vs DMA priority (a design decision, covered as the arbitration subject); heavy contention is mitigated by a bus matrix.

12. What Comes Next

You can now trace the multi-master path. The remaining case studies build out full systems:

• Boot ROM Access (next) — the reset boot fetch path over AHB.
• Debug Subsystem, Microcontroller Bus Fabric, and Low-Power Peripheral Access — a debug access port, a full MCU fabric, and gated low-power access.

To revisit the multi-master structure this trace applies, see Why Arbitration, HBUSREQ / HGRANT, HMASTER, Bus Ownership Handover, and Multiple Masters.