Reading an I²C Timing Diagram

Chapter 4.1 built a legal clock and Chapter 4.2 built a legal data relationship. Each was developed one relationship at a time, with one figure per idea, because that is how a design is written.

It is not how a specification is read. Open the timing section of NXP's UM10204 and you meet a single figure carrying every relationship simultaneously, with a dozen labelled arrows crossing each other and symbols whose subscripts are doing real work. The first encounter is genuinely intimidating, and the intimidation is not a sign that the reader lacks knowledge — it is a sign that they lack a method.

This chapter is the method. It is deliberately procedural, and it transfers: the same seven passes work on an SPI diagram, a DDR command diagram or a memory datasheet, because they are about how timing diagrams are constructed rather than about I²C.

1. Why One Figure Is Hard

A specification diagram and a teaching diagram have different jobs, and confusing them is the source of the difficulty.

A teaching figure isolates one relationship so it can be understood. Every waveform in Chapters 4.1 and 4.2 does that: one idea, two signals, a phase band and three markers at most.

A specification figure is a contract. It must show every constrained relationship in one place, because an implementer needs to satisfy all of them simultaneously and a diagram that showed them separately would let somebody satisfy each in isolation and violate a combination. Its density is not poor design — it is completeness, and the cost of completeness is that it cannot be read in one pass.

So do not try. Read it seven times, asking one question each time.

2. Pass 1 — Which Signals, and Who Drives Them

Start by ignoring every annotation and identifying the rows.

On an I²C diagram there are two: SDA and SCL. That is worth stating because dense figures often appear to have more — a row may be split to show a segment driven by the controller and a segment driven by a target, or drawn with both levels to indicate "either value, held stable". Those are presentational devices on two conductors, not additional signals.

Then ask the question that orients everything else: for each interval, who is driving? A specification figure usually distinguishes this by line style or shading, and it matters because a timing requirement is an obligation on somebody. An interval where the target drives SDA carries target obligations; the same row a moment later may carry the controller's. Pass 7 returns to this properly.

3. Pass 2 — Which Edges Are Meaningful

Now look only at transitions, and sort them into two groups.

SCL edges structure the bit. Its falling edge opens the preparation phase; its rising edge opens the observation phase. Every horizontal measurement on the figure begins or ends at one of these, which is why they are the anchors.

SDA edges carry information — or framing. Chapter 4.2 established the discriminator, and it is the single most useful thing to have in mind while reading: an SDA edge during SCL LOW is ordinary data preparation; an SDA edge during SCL HIGH is reserved, and cannot be data.

So on a first sweep through the SDA row, classify each edge by which SCL phase it sits in. That one sort turns an undifferentiated set of transitions into two meaningfully different kinds of event, and it is the pass that makes the rest tractable.

4. Pass 3 — Where the Data Is Stable

Third pass: shade the intervals during which SDA must not move.

The alternation is the skeleton of the whole diagram: prepare, observe, prepare, observe. Once you can see that rhythm, a dense figure stops being a wall and becomes a sequence, and you can locate yourself in it.

5. Pass 4 — Where the Framing Events Are

Fourth pass: find the SDA edges that sit inside an observation window. Pass 2 already classified them; now use them as landmarks.

These are the framing events, and for reading purposes they matter because they tell you where transfers begin and end — which tells you which parts of the figure are ordinary data and which are boundaries. A dense specification figure often shows a complete transfer, so it contains framing at both ends and data in the middle, and knowing which is which determines whether a given measurement arrow is a data requirement or a framing requirement.

This chapter goes no further than "these are the boundaries." Which direction of edge means what, and what a device does in response, is Module 5. The reading skill needs only the landmark.

6. Pass 5 — The Horizontal Intervals

Fifth pass, and the one people wrongly start with: the measurement arrows.

They are horizontal because they measure durations, and they fall into a small number of families. Recognising the family is more useful than memorising the symbol, because the family tells you what kind of obligation it is:

Two reading habits make these tractable.

Read the anchors, not the name. Every arrow starts at one event and ends at another. Identify those two events and you know what the requirement constrains, even if the subscript is unfamiliar. A symbol you have never seen becomes legible the moment you see that it runs from an SDA edge to the next SCL rising edge — that is a setup time, whatever it is called.

Ask whether it is a minimum or a maximum, because the two are satisfied in opposite directions. A minimum says "at least this long", so more is safe. A maximum says "at most", so more is a violation. Getting this backwards is the rounding bug from Chapter 4.1 in a different guise.

7. Pass 6 — The Vertical Transitions

Sixth pass: stop treating edges as instantaneous.

A specification figure draws SDA and SCL transitions as sloped rather than vertical, and that slope is a real constraint with its own measurement arrows. Chapter 2.4 explained why the two directions differ: a falling edge is actively driven and sharp, while a rising edge is a pull-up charging bus capacitance and is therefore slower and curved.

Two consequences matter for reading a diagram, and both are easy to miss:

Edge time is a constrained quantity, not an artefact of the drawing. There are limits on how slowly an edge may transition, and they exist because a slow edge consumes part of the interval that was supposed to be a stable observation window.

The horizontal measurements are anchored at thresholds, not at the start of an edge. A phase duration is measured between the points where the signal crosses defined levels. So a slow edge does not merely look different — it shortens the interval the receiver actually gets, because part of the time the line spends between levels counts against neither phase cleanly. This is why a design can satisfy every count in RTL and still fail on a heavily loaded board, and it is the single most valuable thing pass 6 contributes.

8. Pass 7 — Who Owes This Requirement

Seventh pass, and the one that turns reading into engineering. For each requirement, ask: whose job is it to satisfy this?

A timing table with no owners is a list of trivia. A timing table with owners is a work breakdown.

Two observations from that table are worth more than the table.

The transmitter of the moment changes. Setup and hold are owed by whoever is driving SDA, and Chapter 3.1 established that this alternates within a transfer — controller on a write, target on a read. So the same arrow on the figure is a different device's obligation depending on where in the transfer you are. A design that only ever considered its own transmit path has verified half of its obligations.

Some requirements are not owed by any chip. Edge times belong to the board. No RTL change fixes a rise time, which is why Chapter 3.3 treats pull-up selection as a design activity rather than a detail, and why a "timing problem" is sometimes a layout problem.

9. Pass 8 in Practice — The Budget Mental Model

The passes end at seven; this is what you do with the result.

A specification interval is not free space. By the time a signal has actually settled at a receiver, the interval has been consumed by real implementation delays:

   interval the specification provides
     - the transmitter's output delay from its internal decision
     - the edge transition time on this board
     - clock and sampling uncertainty in the receiver
     ------------------------------------------------------
     = margin actually left for the receiver

The lesson, and it is why this section exists at all: specification margin is consumed by implementation. A design that arranges to satisfy a minimum exactly has no margin, and the things in that subtraction are not constants — they move with temperature, with supply, with which devices are fitted, and with how the board is laid out.

Module 11.9 performs this with real values. What Module 4 establishes is the habit of asking where an interval went, rather than assuming that meeting a number on paper means meeting it in silicon.

10. Reading a Real Capture

The seven passes work on a specification figure. On an oscilloscope capture, the same structure applies with one addition and one subtraction.

The addition: you can see the edge shapes, which a logic analyser discards. That makes pass 6 a measurement rather than an inference.

The subtraction: nothing is labelled. There are no arrows, no symbols, and no indication of who was driving.

So the questions change from "what does this label mean" to a diagnostic sequence — and asking them in this order is what separates a productive session from an afternoon of staring:

1. Is each LOW phase long enough? Measure one, at the thresholds.
2. Is each HIGH phase long enough? Separately, and not by dividing the period. Chapter 4.1 §9 is the whole argument for why.
3. What shape are the edges? A slow rise is the most common electrical fault on this bus.
4. Is SDA stable through every HIGH phase? The Chapter 4.2 rule, checked by eye.
5. Where are the framing edges? They tell you where transfers begin, which orients everything else.
6. Which is the first interval that is wrong? Not the first byte that decoded wrong — the first timing interval that is out of bounds. Failures cascade, and the first violation is the one worth investigating.
7. Is it repeated or intermittent? Repeated suggests a design or configuration error; intermittent suggests marginal timing that loading, temperature or part variation pushes over.
8. Does it change with loading? Add or remove a device and re-measure. This separates a board problem from a design problem faster than any amount of reading.

11. Debugging — The Diagram That Was Read Backwards

// An engineer implements a controller by working through the specification's
// timing table row by row, converting each number into a cycle count:
//
//   t_LOW  minimum  -> LOW_CYCLES   = ceil(...)      correct
//   t_HIGH minimum  -> HIGH_CYCLES  = ceil(...)      correct
//   t_SU;DAT minimum -> "setup: make sure data is ready N cycles early"
//   t_HD;DAT minimum -> "hold: keep data N cycles after"
//
// Every count is computed with the right rounding. The phase generator measures
// exactly. The engineer then implements setup and hold as DELAYS AROUND THE DATA
// LAUNCH, both counted from the same event -- the data launch itself:
//
//   launch data
//   wait SETUP_CYCLES
//   release SCL            // rising edge
//   wait HOLD_CYCLES       // "hold after the launch"
//   ... next bit
//
// Each number from the table appears in the design. None of the RELATIONSHIPS
// from the diagram does.

// Anchor each requirement on the events the DIAGRAM anchors it on:
//
//   setup: from the SDA change  ->  to the SCL rising edge
//   hold:  from the SCL edge    ->  to the next permitted SDA change
//
// In the phase model from Chapter 4.1 that means launching data early in the LOW
// phase (which gives setup the rest of the phase) and not permitting the next SDA
// change until the required interval after the SCL edge -- two independent
// constraints anchored on two different events, neither derived from the other.
//
// And because the SCL edge is an OBSERVED bus event rather than a counter value,
// a robust controller waits for SCL to actually be high (Chapter 4.1, section 7)
// rather than assuming its count describes the bus.
//
// The verification that catches it: a checker that MEASURES from the specified
// anchor events, not one that confirms the design's own constants. Ask "how long
// after the SCL edge did SDA next move" -- a question the buggy design cannot
// answer about itself, because it never measured that pair.
//
// The review habit that prevents it: walk the DIAGRAM, not the table. For each
// arrow, name its two endpoints out loud and find those two events in the RTL.

The engineering lesson: a timing table is a lossy summary of a timing diagram. The numbers survive the summarisation and the anchors do not, so a design built from the table alone can contain every correct value and the wrong relationships — and it will pass a review that also works from the table. This is the strongest argument for the method in this chapter: the passes recover exactly the information the table discards, and pass 5's "read the anchors, not the name" is the specific habit that prevents this failure.

12. Common Misconceptions

13. Reason It Through

Work these through before reading the answers.

You meet an arrow labelled with a symbol you have never seen. It runs from an SDA transition to the next SCL rising edge. What kind of requirement is it, and who owes it?

A setup time, and it is owed by whichever participant is driving SDA at that moment. You can say both things without knowing the symbol, which is the entire point of reading anchors rather than names — and the second half matters because on a read the owner is the target, not the controller.

A capture shows the correct SCL frequency, correct-looking bytes, and a slow rising edge on SCL. Which passes are relevant, and what is the likely consequence?

Passes 6 and 5, in that order. The slow rise is pass 6 — an edge-time question owed by the board. Its consequence lands in pass 5: because the HIGH phase is measured between threshold crossings, a slow rise eats into the interval the receiver actually gets, so t_HIGH as observed can be below its minimum while the period is correct. Correct bytes prove nothing here, for the reasons Chapter 4.2 gives.

Your design satisfies every minimum in the table exactly. Is that a good design?

No — it is a design with zero margin. The budget in §9 shows that the interval is consumed by output delay, edge transition and sampling uncertainty before the receiver benefits from any of it, and none of those is constant across temperature, supply, fitted devices or layout. Satisfying a minimum exactly means the first variation in any of them produces a violation. Aim above the minimum deliberately.

Two engineers disagree: one says a timing failure is an RTL bug, the other says it is a board problem. How would you settle it?

By identifying which requirement is violated and looking up its owner — pass 7. If a phase duration is short, that is the controller's timing engine, and it is RTL or configuration. If an edge is too slow, that is pull-up and capacitance, and no RTL change fixes it. If setup or hold is violated, it is the current transmitter's launch placement — which is RTL, but possibly pushed over by an edge that arrived late, in which case both engineers are describing the same failure from different ends. Measuring the specific interval settles it; arguing about categories does not.

14. Understanding Check

15. Summary

A specification timing diagram is a contract, not an explanation. It shows every constrained relationship at once because an implementer must satisfy them simultaneously, and that density is why it cannot be read in a single pass.

The method is seven passes: which signals and who drives them; which edges are meaningful — with Chapter 4.2's discriminator sorting SDA edges into data and reserved; where the data is stable, which exposes the prepare-observe rhythm the whole figure is built on; where the framing events are, as landmarks; the horizontal intervals, read by their anchors and their family rather than their symbols; the vertical transitions, which are constrained quantities that shorten the intervals a receiver actually gets; and who owes each requirement, which turns a table of trivia into a work breakdown.

Two habits carry the most weight. Read an arrow's anchors, not its name — that makes an unfamiliar symbol legible and prevents the failure in §11, where a design contained every correct number and the wrong relationships. And ask where an interval went: specification margin is consumed by output delay, edge transition and sampling uncertainty, so satisfying a minimum exactly is a design with no margin against quantities that are not constant.

On a real capture the same structure applies with edge shapes visible and nothing labelled, which turns the passes into a diagnostic order — and frequency is the least useful measurement on this bus, because every requirement that matters concerns an individual phase, edge or relationship.

16. What Comes Next

Module 4 is complete. The bus now has a legal clock, a legal data relationship, and a method for reading the contract that specifies both.

It also has one loose end, deliberately left. Chapter 4.2 showed that an SDA edge while SCL is HIGH cannot be ordinary data, and that the bus therefore reserves that pattern — then stopped, without saying what the reserved patterns mean.

Module 5 — START, STOP & Bus Framing collects that debt. It establishes what a free bus is, what the two reserved edges signify, how a transfer is begun and ended, why a controller would begin a second transfer without releasing the bus in between, and what malformed framing looks like. Everything it does is built on the rule this module derived: framing works precisely because ordinary data can never imitate it.

The detailed numeric parameters this module kept pointing at — the phase minimums, the setup and hold margins, the edge limits and the budget that combines them — are Module 11.

Browse the full path on the I²C tutorials index.