Transaction Lifecycle

Chapter 3.6 followed information through the blocks. This chapter follows a transaction through time, and closes Module 3 by running the assembled system.

What is the high-level lifetime of one Wishbone transaction, from a master's decision to act through slave termination and back to the caller?

This is deliberately not the handshake tutorial. Module 5 owns the cycle-by-cycle timing rules; what belongs here is the shape of a transaction's life and, crucially, which parts of it may vary between conforming implementations.

1. The Lifecycle

Two observations about the shape.

The only message the slave sends during the active phase is silence. That is not a drawing convenience — Classic has no stall signal, so withholding all three terminations is how a slave says not yet. A reader coming from a valid/ready protocol expects a signal here and there is none.

The master's contribution to the active phase is also passive: it holds. RULE 3.60 makes the request signals meaningful under STB_O, so the master's obligation for the whole duration is to not move.

2. What Is Fixed, and What May Vary

This is the distinction that makes the lifecycle useful rather than a description of one design.

Read the right column as the list of things you cannot assume about someone else's Wishbone block. A master written against "slaves answer in one cycle" is not a Wishbone master; it is a master that works with the slaves it was tested against.

And note what is absent from the fixed column: any timeout. Nothing in the protocol bounds the active phase. A slave that never terminates hangs the master indefinitely, and the answer must come from the system — the default slave of Chapter 3.5 for unmapped addresses, and a deliberate design decision for everything else.

3. Waveform — The Same Transaction, Twice

Cycles 5 and 6 are the chapter. CYC_O and STB_O are asserted, ADR_O shows a continuation rather than a new value, and no termination signal exists to look at. The slave is working and the only evidence is the absence of an answer.

Compare the master's behaviour in the two transactions: it is identical. It established, it held, it captured on termination. The first took one cycle and the second took four, and nothing in the master knew or cared. That is the property the whole module has been building toward, and it is why Chapter 3.3 insisted the master must not know latency.

4. Running the Assembled System

Module 3's three modules — 3.3's master, 3.4's slave and 3.5's INTERCON — were composed in 3.6 as wb_soc. The whole system elaborates and runs.

The system under test. One wb_copy_master, one wb_intercon, three instances of wb_gpio_slave at 0x4000_0000, 0x4000_1000 and 0x4000_2000, 4 KiB each. gpio2's input pins are held at 0x5A.

Three scenarios, and the actual trace.

=== wb_copy_master -> wb_intercon -> 3x wb_gpio_slave ===

-- A: copy gpio2.IN (0x4000_2008) -> gpio1.OUT (0x4000_1004) --
  t=65  ADR=40002008 WE=0 | s_stb=100 s_adr=008 | ack=1 err=0 DAT_I=0000005a
  t=75  ADR=40001004 WE=1 | s_stb=010 s_adr=004 | ack=1 err=0 DAT_I=00000000
  -> done, error_o=0
     gpio1 pins_out = 5a

-- B: unmapped destination 0x5000_0000 --
  t=115 ADR=40002008 WE=0 | s_stb=100 s_adr=008 | ack=1 err=0 DAT_I=0000005a
  t=125 ADR=50000000 WE=1 | s_stb=000 s_adr=000 | ack=0 err=0 DAT_I=00000000
  t=135 ADR=50000000 WE=1 | s_stb=000 s_adr=000 | ack=0 err=1 DAT_I=00000000
  -> done, error_o=1

-- C: write to read-only gpio0.IN (0x4000_0008) --
  t=175 ADR=40002008 WE=0 | s_stb=100 s_adr=008 | ack=1 err=0 DAT_I=0000005a
  t=185 ADR=40000008 WE=1 | s_stb=001 s_adr=008 | ack=0 err=1 DAT_I=00000000
  -> done, error_o=1

terminations: ACK=4  ERR=2      conformance violations: 0

What each scenario demonstrates.

A — the architecture actually works. The read at t=65 strobed slave 2 only (s_stb=100), the address arrived as local offset 008, and DAT_I came back as 0x5A — the value physically present on gpio2's pins. The write at t=75 strobed slave 1, offset 004, and gpio1 pins_out became 0x5A. A value moved between two peripherals through decode, broadcast, selection and response merge, and no slave contains an address constant.

B — the default slave earns its place. At t=125 the address was unmapped: s_stb=000, nothing strobed, and no termination. One cycle later err=1 — the INTERCON's registered one-shot answering on behalf of nobody. The master received a termination and reported an error rather than hanging. Remove that logic and this scenario is a dead system.

C — termination is a three-way choice, and it is load-bearing. The write to a read-only register strobed the correct slave, which classified the access, declined to change state, and ended the transfer with ERR_O rather than ACK_O. The master's error_o reflected it. A design with only an acknowledge would have reported success on a write that did not happen.

Zero conformance violations across all three, with live checks on RULE 3.25 (CYC_O whenever STB_O), RULE 3.45 (at most one termination at the master), RULE 3.35 (no slave terminated unstrobed), and the INTERCON's one-hot-or-zero strobe.

5. The Module 3 Verification Checklist

Every architectural property Module 3 established, in one place, with what it protects and where it belongs.

Two structural observations.

Property 10 is bound twice deliberately — at the INTERCON that could create the fault and at the master that suffers it. It is the one fault for which no endpoint is responsible, so binding it only where the obligation formally sits would leave it unchecked.

Property 11 is the only one with a time bound, because it is the only liveness claim. Eventually terminates cannot be refuted by a finite trace, so bounding it is what makes it checkable — and choosing the bound forces the default slave's latency to be stated.

6. What the Learner Should Now Be Able to Answer

Module 3's test is not signal recall. It is these nine questions.

7. Common Mistakes

"A Wishbone transaction takes a fixed number of cycles."

Wrong mental model: the protocol defines a transfer's duration.

Concrete bug: a master that samples read data a fixed number of cycles after asserting its strobe, which works against the slave it was tested with and fails against any other.

Observable evidence: reads returning the previous transfer's data, or zero, when a new peripheral is added.

Correct model: the active phase has no fixed length. The master learns it is over by observing a termination, and read data is meaningful in that cycle only.

"There must be a signal that says the slave is busy."

Wrong mental model: every protocol has a stall or ready indication.

Concrete bug: a master waiting for a signal that does not exist, or an INTERCON inventing one and coupling both ends to a private convention.

Observable evidence: a master that never issues a second transfer, or a fabric that only works with its own slaves.

Correct model: in Wishbone Classic the absence of a termination is the wait. B4's optional pipelined mode does add a stall signal, and conflating the two modes is a common source of this error.

"An unmapped access will produce an error somewhere."

Wrong mental model: the system has a sensible default.

Concrete bug: no default slave. Nothing is strobed, nothing terminates, and the master waits forever on a stray pointer.

Observable evidence: a reproducible hang on one address with every slave's strobe low.

Correct model: unmapped behaviour is entirely the integrator's. The default slave is something you build, and whether it errors or returns zeros is a policy choice the specification does not make.

"Learning the signal names is learning Wishbone."

Wrong mental model: the protocol is a table.

Concrete bug: a block that drives every signal with correct names and violates RULE 3.35 by terminating on STB_I alone — passing point-to-point and corrupting a shared system.

Observable evidence: a peripheral that works in a demo and breaks on integration.

Correct model: the signals encode a set of responsibilities. Module 3 taught who owns what, who selects, who terminates and what may vary. Module 4 now names the signals, and they read as answers rather than as vocabulary.

8. Interview Reasoning

9. Understanding Check

10. What's Next

Module 3 is complete, and its argument is one chain.

Wishbone names four roles and specifies two of them as interfaces, leaving the fabric to the integrator. The model is two levels: a master opens a cycle, presents transfers inside it, and exactly one addressed slave ends each with one of three terminations — which is why describing it as valid/ready renamed is wrong rather than imprecise. A master owns its request and holds it while refusing to know the map, the latency, the internals or the topology. A slave observes, decides and terminates while refusing to know its own base. The INTERCON does the four jobs neither endpoint may. Data flows out with one transformation and back with none. And a transaction's life has three phases of which only the middle one varies.

The system built from all of that runs, moves real values between peripherals, errors rather than hangs on an unmapped address, and violates none of the rules cited along the way.

What Module 3 has not done is define the signals. They have been named where a real interface required it and explained only as far as the architecture needed — CYC_O as tenure, STB_O as qualification, ACK_O/ERR_O/RTY_O as the three endings. None has had its own treatment.

What exactly does each Wishbone signal encode — its width, its direction, its permitted values, when it may change, what a master must do with it, what a slave must do with it, and what goes wrong when it is misused?

Module 4 — Wishbone Signals Deep Dive answers that signal by signal, beginning with the clock every transfer is referenced to. Module 5 then owns the handshake that binds them in time; it has not shipped yet, which is why it is bold rather than linked. The full path is on the Wishbone curriculum index.