Slave Requirements — Responding Without Owning the Clock

Module 17 built a master: thirteen chapters that began by deriving four independent time bases and ended with a synthesizable, parameterised block. This module builds the device on the other end of the same two wires.

It is not the same design with the arrows reversed. It is a harder problem, and one sentence says why.

1. The Asymmetry

Compare what each device knows at the start of a bit slot:

The last row is the one that shapes the architecture. A master that is not ready can take as long as it likes: nothing happens until it clocks. A target that is not ready has a master already clocking at it, and exactly one legal way to say wait — hold SCL low. Everything else it must do in the time the master allows.

2. Therefore the Architecture Is Observation-Driven

Chapter 17.1 §2 derived the master from four time bases, and noted that two of them were driven by reading the bus back. In a target, all of them are.

So the design cannot be organised around what the device intends. It has to be organised around what it has just observed:

two asynchronous wires
   -> synchronised levels and edges              (18.2)
      -> framing: START, repeated START, STOP    (18.3)
         -> the address byte, and whether it is ours   (18.4)
            -> the acknowledge we owe             (18.5)
               -> bytes in                        (18.6)
               -> bytes out                       (18.7)
                  -> the master's answer          (18.8)
                     -> the register file          (18.9)
                        -> what survives a restart (18.10)
                           -> the FSM, derived last (18.11)

Each layer consumes only what the layer below reports. Nothing reaches down to a pin, and nothing above 18.2 knows that pins exist.

3. Intent and Observation Must Stay Separate

This module inherits the distinction Module 17 maintained throughout, and leans on it harder.

sda_in,  scl_in          what the bus IS        -- authoritative for every decision
sda_drive_low            what we are DOING      -- an intent, never a level to read back
scl_drive_low            ... if we stretch      -- 18.10

And the open-drain contract is unchanged, because it is a property of the bus rather than of either role:

drive_low = 1   ->  pull the line LOW
drive_low = 0   ->  RELEASE it

There is no drive-high. A transmitted one is a release — which for a target means that sending 0xFF on a read is done by driving nothing at all, and Chapter 18.7 tests exactly that.

4. What a Target Must Do, Enumerated

Stated as obligations rather than as states, because the states come later:

Wait for a START. Until one arrives, nothing on the bus concerns this device. 18.3.

Shift in eight bits and decide whether they name it. The comparison is trivial; the three-way separation of receive, compare and answer is not. 18.4.

Acknowledge, in the right slot, and let go in time. The acknowledge is an ownership transfer, and the window is bounded at both ends by falling edges. 18.5.

Latch the direction and obey it for the rest of the transfer, because the address byte will not be on the wire any more. 18.4.

Receive, or transmit — and on a transmit, have the byte ready before the master asks for it. 18.6, 18.7.

Read the master's answer on a read, and stop when it says stop. 18.8.

Go quiet when not selected, and stay quiet until the next START. 18.4.

Separate protocol state from application state, because a repeated START restarts the frame and must not destroy a register pointer. 18.10.

Stretch only if it must, and release when it is ready. 18.10.

5. The Architecture, Drawn

Two features of that picture are the argument of this module.

There is exactly one path in from the pins, and it goes through 18.2. Nothing else reads a pin. That is what makes the rest of the design testable: every block above has synchronous inputs and no notion of an asynchronous bus.

Only two blocks have drive intent — the acknowledge generator and the transmit path — plus the stretch controller in 18.10. Everything else is pure observation, which means most of this design cannot damage the bus even if it is wrong.

6. Why This Chapter Carries No RTL

This is the same judgement Chapter 5.1 made, and for a comparable reason: some chapters establish the terms in which the later ones are stated.

7. Verification Connection — The Controller BFM and the Target DUT

   // Verifying a target inverts the environment of Module 17, and the inversion is not
   // cosmetic: it changes which component has to be trustworthy.
   //
   //   MODULE 17: the master was the DUT. The environment supplied a TARGET MODEL, and
   //              Chapter 17.1 §10 showed that a permissive model -- one that never
   //              stretched -- silently certified a non-compliant master.
   //
   //   MODULE 18: the target is the DUT. The environment must supply a CONTROLLER, and
   //              now the controller is the thing whose correctness the whole result
   //              depends on. A BFM that drives framing and data the same way cannot
   //              distinguish a target that checks the SCL level from one that does not.
   //
   // WHICH IS WHY THIS MODULE'S BENCHES DRIVE THE PINS BY HAND. Each one contains a
   // small controller written as tasks -- gen_start, gen_bit, gen_byte, gen_stop -- that
   // changes SDA only while SCL is LOW for data and only while SCL is HIGH for framing.
   // That distinction is the entire content of Chapter 18.3, so a bench that blurred it
   // would be unable to test the block it exists to test.
   //
   // THE FOUR COMPONENTS, and what each is for:
   //
   //   controller BFM    generates the stimulus: framing, clocks, address, data. Owns
   //                     the clock, so it owns every deadline the DUT must meet.
   //
   //   pin-level monitor reconstructs the protocol from the two wires ONLY. It must not
   //                     peek at the DUT -- Chapter 17.1 §8's observability boundary --
   //                     because a monitor that reads the DUT's intent will pass a target
   //                     whose intent is right and whose pad is broken.
   //
   //   application predictor  models the register file: what the pointer should be, what
   //                     a read should return. This is the Module 16 model, reused.
   //
   //   scoreboard        compares what the monitor saw against what the predictor expected.
   //
   // AND THE HARDEST THING TO GET RIGHT is the BFM's timing, not the DUT's. A target that
   // fails against a correct BFM has a bug. A target that PASSES against a BFM which
   // clocks too slowly, never stretches, or always sends 0xFF has told you nothing -- and
   // each of those is a real bench that looked fine. Module 17's recurring lesson,
   // arriving from the other side.

8. FPGA and ASIC Context

Both realisations are Module 19's subject, and this module deliberately stops at the boundary. What matters here is only the shape of the seam.

The pins are three signals, not two. drive_low out, the line in, and the pad's output enable derived from the first — Chapter 17.1 §4's contract, unchanged by the change of role. An inout in synthesizable RTL is neither synthesizable nor safely simulatable against a second driver.

The inputs are asynchronous, and that is 18.2's problem to contain. Its output is a synchronous event set, and the depth of the synchroniser, the metastability argument, spike filtering and oversampling ratios are all deferred to 19.4 and 19.5. This module treats two flops as a stated contract and uses only one consequence of it: every event arrives late, and lateness has a direction that is safe for some obligations and not for others.

A target has no clock of its own on the bus, but it does have a system clock — and the ratio between them is a design constraint rather than a free choice. Chapter 18.5 is where it first bites: the acknowledge must be asserted inside one SCL low phase, so the system clock must be fast enough that the synchroniser latency plus the decision fits inside it. Module 19.6 owns the constraint arithmetic.

9. Common Misconceptions

"A target is a master with the arrows reversed." A master decides when events happen; a target detects them. Every time base in a target is driven by observation, which changes the architecture rather than the direction of a few ports. §1.

"A target only needs SDA." SDA alone is meaningless. A falling edge on SDA is a START if SCL is high and an ordinary data bit if it is low, and those are the two most different things on the bus. §3 and 18.3.

"A target can take its time." Only by holding SCL low, and only if its design supports doing so. Otherwise every deadline belongs to the master. §1.

"Transmitting a one means driving SDA high." There is no drive-high anywhere in a conforming I²C interface. A one is a release, so 0xFF is sent by driving nothing. §3.

"The target can read back its own drive to know the line state." Its drive is an intent. The line is the wired-AND of every device, and for a target the observed line is not feedback — it is the only input. §3.

"The FSM is the design." The FSM is what remains once every block that owns a time base has been built. Written first, it absorbs all of them and becomes untestable. §2.

"A repeated START resets the device." It restarts the frame. Whether it resets application state — a register pointer, say — is a separate decision, and getting it wrong breaks the combined transfer that register devices depend on. §4 and 18.10.

"An environment that drives a target correctly is the easy part." It is the part everything else depends on. A BFM that never stretches, clocks too slowly, or blurs framing and data cannot test the properties those distinctions exist for. §7.

10. Reason It Through

Why can a target not be derived by inverting the master's architecture?

Because the master's four time bases advance on events it produces, and the target's all advance on events it observes. The direction of the ports changes; the direction of causation changes too, and that is what determines the decomposition. §1 and §2.

A target is handed only SDA, sampled at a fixed high rate. What can it not determine?

Anything at all. A falling edge on SDA is a START when SCL is high and ordinary data preparation when it is low — so without SCL, the single most important classification on the bus is unavailable. §3.

Which is the only thing a target may refuse, and what follows if its design cannot do it?

It may refuse to be hurried, by holding SCL low. A target without a stretch capability must meet every deadline the master sets, which makes its datapath latency a correctness property rather than a performance one. §1 and 18.10.

Why does only one block in the target read a pin?

So that every other block has synchronous inputs and no notion of an asynchronous bus — which is what makes them individually testable. It also guarantees a single view of each wire: two synchronisers can disagree about what the bus did. §5.

Most of this design cannot damage the bus even if it is wrong. Why, and which parts can?

Because only three blocks have drive intent — the acknowledge generator, the transmit path and the stretch controller. Everything else is pure observation, so a defect there produces wrong conclusions rather than a wedged bus. §5.

Why is a permissive controller BFM more dangerous when the target is the DUT than a permissive target model was when the master was?

Because the BFM owns the clock, and therefore owns every deadline the DUT must meet. A BFM that clocks slowly, never stretches or always sends the same byte relaxes the exact constraints the target is supposed to satisfy. §7.

11. Understanding Check

12. Summary

A master decides when things happen; a target finds out. Every event that structures a transfer is produced by the master, and the target's only evidence is two wires.

So all of the target's time bases are observation-driven, where only two of the master's were. That changes the architecture rather than merely the direction of some ports.

The only thing a target may refuse is to be hurried, by holding SCL low. Without a stretch capability, its datapath latency becomes a correctness property.

Intent and observation must stay separate, and for a target the observed lines are not feedback — they are the entire input.

The open-drain contract is unchanged, because it belongs to the bus and not to either role: drive low or release, and a transmitted one is a release.

Exactly one block reads a pin. That is what makes every block above it testable, and it guarantees a single consistent view of each wire.

Only three blocks can disturb the bus — acknowledge, transmit and stretch — so most of this design produces wrong conclusions rather than wedged buses when it is wrong.

The FSM is derived last, exactly as in Module 17, because every state belonging to a time base already lives in the block that owns it.

Verifying a target inverts the environment, and the controller BFM becomes the component whose correctness everything depends on — a strictly more dangerous position than the target model occupied in Module 17, because the BFM owns every deadline.

And this chapter carries no RTL deliberately. Its content is an asymmetry and a decomposition; the event vocabulary that any block here would need is 18.2's subject.

13. What Comes Next

Chapter 18.2 builds the block every other one in this module is written against: the sampling front end that turns two asynchronous wires into a small set of synchronous events.

It is a short block with a long argument, because three of its decisions are the kind that produce defects nothing later can recover from — what the samplers reset to, which signals the edge pulses are derived from, and why the synchroniser belongs there and nowhere else.

It also establishes the one fact this module keeps returning to: every event a target sees arrives late, and the direction of that lateness decides which obligations are safe.