Bus Idle and the Framing Primitives

Chapter 4.2 derived a single rule and then deliberately stopped one step short of its consequence. The rule was that SDA must be stable while SCL is high. The consequence was that an SDA edge during SCL high cannot be an ordinary data bit — and rather than calling that an error, the bus reserves it.

Reserves it for what, the chapter did not say. This module collects that debt, and this chapter sets up the collection: before naming a single framing event, it is worth establishing what state the bus is in when nothing is happening, and why a two-wire shared bus has no choice but to mark the beginning and end of its own transfers.

1. Why a Shared Bus Must Delimit Itself

Start with what I²C does not have, because that is what forces the design.

There is no chip-select conductor. Chapter 1.4 compared the buses on exactly this point: SPI delimits a transfer with a dedicated select line per device, so the beginning of a transfer is a wire going active and the end is that wire going inactive. The framing is out-of-band — it does not consume the data path, and it cannot be confused with data, because it is physically a different conductor.

I²C spent that conductor. It has two, and both are committed: one carries the information, one carries the timing. There is no third wire available to mean "a transfer is starting now".

There is also no frame-length field and no idle-pattern convention. An asynchronous serial line delimits a character with a start bit and a stop bit at a rate both ends already agreed on, which works because the receiver knows in advance how many bit times a character occupies. I²C makes no such agreement: Chapter 4.1 established that the controller supplies the clock precisely so the two ends need not have agreed on a rate beforehand, and Chapter 7.1 will establish that the number of bytes in a transfer is not fixed.

So the delimiters have to live in band, on the two conductors that already exist, and they have to be distinguishable from every possible data pattern. That last requirement is the hard one. If a delimiter were merely an unusual data pattern — some reserved byte value — then a transfer carrying that value as payload would be indistinguishable from a transfer ending, and the bus would need an escaping scheme. Escaping works, but it costs bandwidth on every byte and it puts the burden on every participant.

I²C avoids all of it by delimiting with something that is not a data pattern at all. Not a special value, but a special relationship between the two lines — one that the data-valid rule has already forbidden ordinary data from ever producing. That is why Module 4 had to come first: the framing does not sit alongside the data rule as a second mechanism, it is carved directly out of the space the data rule leaves empty.

2. Idle: Both Lines Released

Before a transfer can begin, the bus has to be in a known state, and the specification is direct about what that state is. UM10204 §3.1.1 says that both SDA and SCL are connected to a positive supply through a pull-up or current source, and that when the bus is free, both lines are HIGH.

Read that against Chapter 2.3 and it says something more specific than it first appears. Both lines are high because nothing is pulling them down. No device is driving a one. Every output stage on the bus is open-drain, so the only thing a device can actively do is pull a line low; the high level is what the pull-up network produces in the absence of any such action. An idle I²C bus is not a bus being held high — it is a bus being left alone.

That distinction has a consequence that shows up in RTL immediately, and Module 4 already relied on it: a controller in reset must release both lines, not drive them. Chapter 4.1 built its phase generator with scl_drive_low deasserted on reset for exactly this reason. A device that held either conductor low while idle would make the bus permanently unusable for every other device, and because the wired-AND of Chapter 2.5 gives every participant an unconditional veto over the low level, one such device is enough to take down the whole segment.

So "idle" is a statement about the absence of drive on two conductors, and it is the precondition every framing event is measured against.

3. Idle Is Not the Same as Free

Here is the first place where careful reading pays, and it is easy to skip because the specification uses both words.

UM10204 §3.1.4 says the bus is considered busy after a START condition, and that it is considered free again a certain time after a STOP condition. That phrase — a certain time — is doing real work. It means the moment a transfer ends is not the moment the next one may begin.

So there are three states worth separating, not two:

The middle row is the one that surprises people. A controller that has just issued a STOP sees both lines go high and may reasonably conclude the bus is available — and it is wrong, because the interval that separates one transfer from the next has not yet elapsed. Chapter 5.3 builds a tracker whose entire job is to keep those two apart, and it will turn out that getting this wrong produces one of the more confusing failure modes on a real bus.

The interval itself has a name and a specified value. Both belong to Module 11, which owns the timing table; this module owns the state machine that the interval sits inside.

4. How Many Reserved Edges Are There?

Now the counting argument, which answers a question most treatments never pose: why are there exactly three framing events, rather than two or five?

Module 4 established that SDA may not change while SCL is high. Ask what that forbids, exhaustively. While SCL is high, SDA can do exactly three things:

1. stay high,
2. stay low,
3. change.

The first two are ordinary data — a settled one and a settled zero, which is precisely what the receiver is there to sample. Only the third is forbidden, and the third subdivides by direction: SDA can change high-to-low, or low-to-high. That is the complete list. There is no third direction, and there is nothing else a single-conductor binary signal can do inside a window.

So the reserved space contains exactly two waveforms, and the bus gets exactly two framing primitives out of it, no more. Any framing vocabulary larger than two has to be built by combining these — by sequence, by repetition, or by context — and cannot be built by inventing a new edge, because there is no new edge to invent.

5. Three Events From Two Edges

The two edges become three named events, and the way that happens is the single most important structural fact in this module.

UM10204 §3.1.4 defines them plainly. A HIGH to LOW transition on SDA while SCL is HIGH defines a START condition. A LOW to HIGH transition on SDA while SCL is HIGH defines a STOP condition. And then the specification adds the sentence that does the real work:

The bus stays busy if a repeated START (Sr) is generated instead of a STOP condition. In this respect, the START (S) and repeated START (Sr) conditions are functionally identical.

So the third event is not a third waveform. A repeated START is the START edge again — the same falling edge, with the same shape, produced by the same driver. What distinguishes it is not anything visible on the two conductors at that instant, but whether a transfer was already in progress when it arrived.

Two consequences follow, and both will shape every design in this module.

A framing detector needs no state; a framing classifier does. Deciding "an SDA edge occurred while SCL was high, in this direction" requires only the two conductors and one sample of history. Deciding "that was a repeated START rather than a first START" requires knowing something the conductors are not telling you. Chapter 5.2 builds the first kind and Chapter 5.4 builds the second, and the difference between them is exactly this sentence.

The specification's own shorthand hides the distinction on purpose. UM10204 states that from that point on, the symbol S is used generically for both START and repeated START unless Sr is specifically relevant. That is a reasonable economy in a specification, and it is a trap when reading one: a figure or a sequence description that says S may mean either, and the reader has to supply the context. Chapter 4.3 made reading-the-anchors a habit for measurement arrows; the same habit applies to framing symbols.

6. What Framing Does Not Provide

It is worth being explicit about the limits, because framing is often expected to carry more than it does.

Framing tells every device on the bus that a transfer has begun and that one has ended. It does not tell them:

• who the transfer is for. Addressing is a separate mechanism carried in the first byte after the START, and it is Module 6.
• how long the transfer is. There is no length field. The transfer is over when a STOP or a repeated START arrives, and not before — which means every participant must be able to handle a transfer of unknown length.
• whether the transfer succeeded. The acknowledge mechanism is per byte, not per transfer, and it is Module 7. A perfectly framed transfer in which every byte was NACKed is still perfectly framed.
• whether the data was correct. There is no checksum, no parity, no CRC at this layer. A transfer that framed correctly and delivered corrupted bytes looks, to the framing layer, exactly like a successful one.

That last point is worth dwelling on because it sets up a debugging habit this module returns to repeatedly. Framing is a bracket, not a guarantee. When a capture shows a clean START and a clean STOP, what has been established is that the transfer's boundaries were legal — and nothing whatever about the content between them.

7. Detection Is a Hardware Obligation

There is one more sentence in UM10204 §3.1.4 that deserves attention, because it is easy to read past and it constrains implementations directly:

Detection of START and STOP conditions by devices connected to the bus is easy if they incorporate the necessary interfacing hardware. However, microcontrollers with no such interface have to sample the SDA line at least twice per clock period to sense the transition.

Two things follow.

Framing detection is a continuous obligation, not a scheduled one. A device does not get to look for a START when it expects one. It has to be watching whenever the bus is not its own, because a START can arrive at any time and a repeated START can arrive in the middle of a transfer the device thought it understood. This is the structural reason framing detection is normally dedicated hardware rather than a software poll.

Sampling rate is a design constraint, and the specification names a floor. "At least twice per clock period" is the minimum a software implementation must manage to see the transition at all. Every detector in this module is a sampled design — it observes the bus on an internal clock, exactly as Chapter 4.2's stability checker did — and inherits that chapter's honest limitation: a sampled detector reasons about samples, not about the bus. Module 19 owns the oversampling and filtering that turn a sampled observation into a reliable one.

8. Ownership — Framing Belongs to the Controller

UM10204 §3.1.4 is unambiguous: START and STOP conditions are always generated by the master. A target never issues framing.

This is worth connecting to Chapter 3.1, which established that the controller owns the clock. Framing ownership follows from clock ownership rather than being a separate rule, and the reason is mechanical: a framing event is defined as an SDA edge while SCL is high. Producing one on purpose therefore requires controlling when SCL is high — and on this bus only the controller does that.

A target can pull SDA low; it does so for every acknowledge and for every byte it transmits. What it cannot do is arrange for SCL to be high at a moment of its choosing, so it cannot manufacture framing even in principle. The asymmetry is not a permission granted by the specification, it is a consequence of the electrical layer.

There is one apparent exception and it is instructive. A target can accidentally produce a framing waveform, by changing SDA while SCL happens to be high — which is precisely the violation Chapter 4.2's checker was built to detect. The bus cannot tell an accidental framing edge from an intentional one; it simply obeys. That is why the data-valid rule is a hard obligation on transmitters rather than a quality target, and it is the failure mode Chapter 5.5 catalogues.

9. FPGA and ASIC Implications

The idle state costs static current, and the design does not control it. Both pull-ups source current continuously whenever a line is low, so bus power is a function of how often the bus is low rather than of how fast it runs. Chapter 2.4 established the sizing trade-off; the framing consequence is that an idle bus is the cheapest state and a bus held low is the most expensive, which is one more reason a stuck-low line is a problem worth detecting.

Reset must release, and on an FPGA that means the tristate control, not the output value. The open-drain output of Chapter 2.3 is built from a tristate buffer whose enable is driven by the design's drive intent. "Release on reset" therefore means the output-enable is deasserted on reset — an FPGA that reset the data input of the buffer while leaving the enable asserted would drive a zero onto the bus and jam it. This is a wiring detail, and it is the wiring detail that most often turns a correct design into a dead bus on first power-on. Module 19 owns the vendor primitives.

A soft reset of the controller is not a reset of the bus. Resetting the controller returns its drive intent to released, which is necessary and not sufficient: if a target is mid-byte and holding SDA low, the bus stays low and no amount of controller reset changes that. A design that assumes "after reset the bus is idle" is assuming something about every other device on the board. Module 16 owns recovery.

10. Debugging — The Bus That Was Never Free

// A controller checks that the bus looks idle before it begins, which is the
// right instinct, implemented as an instantaneous test:
//
//   wait until (scl_in == 1'b1 && sda_in == 1'b1);   // "bus is idle"
//   issue_start();
//
// On the bench, against a single target and with the analyser as the only other
// thing on the bus, this works every time. The controller is the only device
// that ever initiates anything, and by the time software asks for a transfer
// the previous one finished long ago -- so the instantaneous test and the real
// requirement agree, and nothing reveals that they are different tests.
//
// The design also resets correctly: both lines are released out of reset, and a
// reviewer checking for the classic open-drain bug finds nothing wrong.

// Make the precondition a STATE, tracked over time, rather than a LEVEL sampled
// at one instant. That state needs three values and not two:
//
//   busy      -- a transfer is in progress
//   released  -- both lines high, but the interval has not elapsed
//   free      -- both lines high for the whole required interval
//
// and a START is permitted only from 'free'. Chapter 5.3 builds exactly this
// tracker, and the reason its counter RESTARTS when a line goes low -- rather
// than pausing -- is this bug: the interval has to be CONTIGUOUS released time,
// so an interruption means starting over, not resuming.
//
// The diagnostic that finds it, once suspected, is cheap: capture with a trigger
// on the STOP condition rather than on the failing address, and measure the
// interval from the STOP to the next START. An instantaneous-test design produces
// a gap of very nearly zero, which is visibly wrong the moment you look for it.
//
// The habit that prevents it: when a specification says "a certain time after",
// that phrase is a state machine, not a comparison. Every requirement of the
// form "X may begin once Y has been true for T" needs a timer, and an
// implementation that samples a level is answering a different question.

11. Common Misconceptions

"An idle I²C bus is driven high." It is released, and the pull-ups do the rest. No device ever drives a one on this bus. The distinction is invisible in a logic-level capture and decisive in RTL — it is the difference between an output-enable that is deasserted and one that is asserted with a one, and the second jams the bus.

"The bus is free as soon as the STOP finishes." It is released as soon as the STOP finishes, and free a specified interval later. §3 separates the two and §10 shows what conflating them costs.

"A repeated START is a different waveform from a START." It is the same edge. Nothing at that instant distinguishes them; only whether a transfer was already in progress does. This is why a classifier needs state and a detector does not.

"START and STOP are symmetric opposites, so anything true of one is true of the other with the direction flipped." They are opposite edges, and their surrounding obligations are not mirror images. A START is followed by the controller taking the clock low; a STOP leaves both lines released and starts an interval. Treating them as one mechanism with a sign flip is how the bus-free requirement gets dropped.

"A device can look for framing when it expects a transfer." It has to watch continuously. A repeated START can arrive at a point the device believed was mid-transfer, and a START can arrive at any time at all.

"Clean framing on a capture means the transfer worked." Framing is a bracket. It says the boundaries were legal and says nothing about address, acknowledgement, or payload — §6 lists exactly what it does not cover.

12. Reason It Through

A colleague proposes adding a fourth framing event to a proprietary variant of the bus, to signal "abort". What is the structural obstacle?

There is no unused edge left. §4's counting argument is exhaustive: while SCL is high SDA can hold high, hold low, or change, and change has two directions. Both directions are already spoken for. A fourth event can only be built by combining existing primitives — a sequence, a repetition, a distinguished pattern in the data that follows — and any such scheme needs every device on the bus to agree on the combination, which is precisely what a proprietary variant cannot assume of parts it did not design.

Why can a target not issue a STOP to escape a transfer it cannot continue?

Because a STOP requires SDA to rise while SCL is high, and the target does not control when SCL is high. It can release SDA at any time, but whether that release lands during a high phase is the controller's decision, not its own. The mechanism a target actually has for pushing back is to hold SCL low — which stalls the clock rather than terminating the transfer — and that is Module 12.

A monitor is enabled in the middle of an active transfer. What can it and can it not conclude?

It can detect subsequent framing edges correctly, because detection needs only two conductors and one sample of history. It cannot know whether the next falling edge it sees is an S or an Sr, because that depends on a bus state it did not observe the beginning of. A monitor in this position has to either declare its state unknown until it sees a STOP — which resynchronises it — or report the edge without classifying it. Chapter 5.4 returns to this.

Two boards use identical controller RTL. One holds SCL low for a few microseconds after power-on; the other does not. What differs, and why is it a framing problem?

The difference is almost certainly which signal the reset touches in the output stage. Releasing means deasserting the tristate enable; a design that instead resets the buffer's data input while the enable stays asserted drives a zero and holds the line low. It is a framing problem because every framing event is defined relative to SCL's level: a bus whose clock line is held low by a device that believes itself idle cannot have a legal START produced on it by anyone.

Why does the bus-free interval have to be contiguous released time rather than cumulative?

Because its purpose is to give every device enough quiet to return to a state where it is watching for a START. A device part-way through that return, interrupted by new bus activity, has not finished — so time accumulated before the interruption bought nothing. This is the design reason Chapter 5.3's tracker reloads its counter instead of pausing it, and §10 is what happens to a design that gets it wrong.

13. Understanding Check

14. Summary

A shared two-wire bus has to delimit its own transfers in band, because it spent its third conductor and makes no prior agreement about rate or length. The delimiters cannot be data patterns, or they would need escaping.

The delimiters are a relationship, not a value — an SDA edge while SCL is high — and the data-valid rule of Chapter 4.2 had already forbidden ordinary data from producing one. Framing costs the bus nothing because the receiver's sampling requirement had already paid for it.

Idle means released, not driven. Both lines are high because nothing pulls them down, which is why a controller in reset must deassert its drive rather than output a value.

Idle, released and free are three states, not two. The bus is busy after a START and free a specified interval after a STOP; the gap between "both lines high" and "free" is where §10's failure lives.

Exactly two edges are reserved, and they produce exactly three events. The falling edge is a START from a free bus and a repeated START from a busy one — the same waveform, classified by state. Nothing visible at that instant separates them, which is why a detector needs no state and a classifier does.

Framing is a bracket and not a guarantee. It carries no address, no length, no acknowledgement and no integrity check.

Framing belongs to the controller, and that follows from clock ownership rather than being an independent rule, because only the device that decides when SCL is high can deliberately place an edge inside a high phase.

15. What Comes Next

The reserved space has been counted and named, and the state the events are measured against has been pinned down. What has not happened yet is any account of what a device actually does when a framing event arrives, or of how one is detected in hardware.

Chapter 5.2 takes the first event on its own terms: what a START does to every device on the bus, and a detector for it built in three languages — the first hardware in this module, and the one every later design in it is assembled from.

Browse the full path on the I²C tutorials index. For the rule the framing is carved out of, see The Data-Valid Rule; for why a released line reads high, Open-Drain Outputs.