"Wishbone Cannot Support DMA"

This claim is a category error, and naming the category is most of the correction.

DMA is a system function. Descriptors, a programming model, interrupts, coherency, scatter-gather, protection — those live in an architecture.

Wishbone is a bus interface. It defines how two endpoints exchange one transfer.

So the question "does Wishbone have a DMA signal?" has no useful answer, because no bus interface has one. The answerable question is:

Can a DMA engine act as a bus master and move data through this system?

1. What A DMA Engine Actually Is

Once the category is straight, the structure is unremarkable:

The engine's Wishbone port is indistinguishable from the CPU's. It asserts CYC_O and STB_O, presents an address, honours RULE 3.60 while the phase is open, and waits for a termination. Nothing in the protocol knows or cares that a state machine rather than a processor produced the request.

2. It Works — Measured

Module 25 built the engine; this re-runs its evidence. Every DMA module here is byte-identical to that module's, and the arbitration rig is lifted verbatim from its own testbench.

  descriptor: source 0x010, destination 0x400, 8 items

  items written to the destination   8 of 8
  clocks the engine was busy         41
  clocks it was stalled by arbitration 25
  protocol violations                0
  CPU transfers completed            0

  destination contents after the transfer
    0xab000000 0xab010001 0xab020002 0xab030003
    0xab040004 0xab050005 0xab060006 0xab070007

Eight items, correct data, zero protocol violations. The engine issued ordinary reads and writes; no DMA signal exists in the protocol and none was needed.

3. Contention Is A Cost, And Its Size Is Not Obvious

Add a CPU hammering the same region the DMA reads from:

  rig                items  busy clocks  arbitration stalls  CPU done  violations
  DMA alone              8           41                  25         0           0
  CPU hammering          8           41                  25       408           0

  destination contents identical to the uncontended run: 8 of 8
  destination matches the source pattern:                8 of 8

  THAT IS THE MEASUREMENT, NOT THE EXPECTATION.
  A zero-wait target is occupied for a single clock, which is
  too short for either master to obstruct the other here.
  Contention is a COST WHOSE SIZE DEPENDS ON THE TARGETS AND
  THE ARBITER, and in this configuration the cost is zero.
  It would not be zero against a slow target, and this
  experiment says nothing about that case.

The CPU completed 408 transfers against the same region, and the DMA took the same 41 clocks it took alone. Every item arrived byte for byte.

This is not the result the chapter expected, and it is the more useful one. Contention is not automatically a cost — its size depends on how long each target is occupied and on how finely the arbiter interleaves. Against a multi-wait target the number would differ, and this experiment says nothing about that.

4. Where It Actually Goes Wrong

Now the same engine, the same bus, and a descriptor whose destination names the wrong region:

  items the engine reports written   8 of 8
  protocol violations                0
  arbitration stalls                 33

  region 0x100 after the transfer
    0xab000000 0xab010001 0xab020002 0xab030003

  region 0x400 - the destination software expected
    0x99990000 0x99990001  (still the seeded pattern)

  The engine reports success. The protocol checker reports
  0 violations. Every transfer was legal, acknowledged and
  delivered - to a region the descriptor named and the
  software did not intend. NOTHING IN A BUS PROTOCOL CAN
  CATCH THIS.

Eight items moved. Eight acknowledgements. Zero violations. The data is sitting in the wrong place and the destination software expects still holds its seeded pattern.

This is the shape of every real DMA failure, and none of it is a bus problem. It is an address map, a descriptor, a programming model — the system around the interface. Chapter 30.3 is where that gets reviewed, and a protocol checker is structurally incapable of helping.

5. What The Bus Does Not Give You

Being explicit here is what makes the correction honest rather than defensive. Wishbone alone defines none of:

A real DMA subsystem may need every one of those. That does not show Wishbone cannot support DMA. It shows a bus protocol is not a complete SoC architecture — which is equally true of every other bus protocol, and is not a comparison between them.

"Supports DMA" and "provides a DMA subsystem" are different claims. The first is what a bus can do; the second is what an architecture must.

6. The Design Consequence

Choosing a protocol to get a DMA subsystem. A protocol with more channels does not supply descriptors, coherency or a programming model either. Selecting on that basis buys capabilities that address a different part of the problem, and the descriptor bug above is unaffected.

Assuming arbitration is a detail. It decided whether the CPU's 408 transfers cost the DMA anything — here, nothing. On a slower target it would decide a great deal, and it is local policy in every case.

Verifying the bus and calling the DMA verified. Section 4 is a system that is completely wrong with a perfectly clean bus. Chapter 30.2's question applies directly: could this environment have detected the defect this design is at risk of containing?

7. The Replacement Statement

8. What To Carry Forward

• Name the category. DMA is a system function; Wishbone is a bus interface.
• The engine's port is an ordinary master port. No DMA signal exists in any bus protocol.
• Contention's cost is measured, not assumed — 408 CPU transfers cost this DMA nothing.
• A wrong descriptor is a perfectly legal transfer. Zero violations, data in the wrong region.
• Distinguish "supports" from "provides." Eight things the bus does not define, and every bus protocol shares that list.

What You Can Now Do

Thirty-one modules end here. The useful summary is not what was covered but what you can now do without looking anything up.

Read an unfamiliar Wishbone interface and say which signals are qualified by what, who drives each one, and which optional signals are absent — and what their absence obliges the rest of the system to guarantee.

Predict a transaction cycle by cycle, at any slave latency, and say which clock the commit happens on and why it is that one.

Separate specification from local policy in your own sentences. B3 requires a handful of things; the address map, arbitration, timeouts, retry policy and error semantics are yours, and saying so correctly is what makes the rest of your claims credible.

Write a master and a slave that hold the request still because there is nothing live left to change, commit exactly once, and qualify their read data.

Design an address map and an interconnect, and sweep the boundaries rather than the interior to prove it.

Reason about ownership — who requested, who owned, who was presented, who terminated, who received the response — as five separate questions.

Integrate a DMA engine and know which of its failures the bus can show you and which it structurally cannot.

Verify invariants rather than counting tests, with negative controls, independent prediction, and stimulus that could have failed.

Debug from evidence: symptom, boundary, invariant, first divergence, proven mechanism — and a regression that failed before the fix.

Review a design and produce dispositions with evidence behind them, including NOT VERIFIED where nobody looked.

Evaluate a protocol trade-off by listing required capabilities against provided ones, scoping both sides, and stating plainly where your preferred answer does not fit.

And one habit underneath all of them, which this final module existed to build: when a confident sentence arrives without its conditions, find the conditions before you act on it. That is the difference between knowing a bus and being able to own a subsystem.