SDA and SCL — The Two-Wire Contract

Module 1 derived a shape and left a debt. The shape is a shared pair of conductors carrying serialised information and its timing, with participants named logically because the wiring no longer names them. The debt is that the derivation used a capability it never justified: it assumed several devices could be attached to the same conductor, take turns using it, and disagree about its level without harming one another.

That assumption is not safe by default, and this module is where it is examined. Before it can be, the two conductors need naming and their contract needs stating — which is this chapter, and deliberately nothing more. What follows here is a description of what the wires are, not yet any account of how they can be shared.

1. Two Lines, and What Each Carries

The bus is two conductors, and their division of labour is the one established in Chapter 1.2.

SDA — serial data. The information conductor. Everything a participant wants to convey — which device is being addressed, the values being written, the values being read back — crosses the bus one bit at a time on this line.

SCL — serial clock. The timing conductor. It marks the instants at which a bit on SDA is meaningful, which is the job Chapter 1.2 identified as the reason the bus spends a second conductor at all rather than bottoming out at one.

A third connection is implied and easy to forget: every device must share a common ground reference, because a voltage on a conductor is only a level relative to something. That is why the bus is often described as two wires and drawn as three connections.

Beyond that division, this chapter takes no position on what patterns on those conductors mean. The rules that turn edges into structure — where a transfer begins, how a device is named, when a bit is valid — are protocol, and they are owned by Modules 4 through 8. Here the lines are just lines.

2. Both Lines Are Bidirectional

This is the part that separates the I²C bus from an ordinary signal, and it is worth stating carefully because "bidirectional" is used loosely elsewhere.

On this bus, neither conductor belongs to a single device. SDA is not an output of one participant and an input of the others; every attached device has both an output capability and an input capability on it, and which device is using it changes within a single transfer. A device that has just received a byte may be the one that responds, and the response travels back along the same conductor that carried the byte.

SCL is bidirectional too, and that surprises people. The timing is normally sourced by whichever participant initiated the transfer — Chapter 3.1 defines those roles properly — but the specification permits other devices to influence SCL as well. A device that needs more time can hold the clock line, and in a system with more than one potential initiator, the clock is a shared resource rather than one device's output. Both of those behaviours are developed later, in Modules 12 and 13 respectively. What matters now is the structural fact: SCL is not an output pin with inputs hanging off it. It is a shared node, exactly as SDA is.

So both conductors have the same electrical situation: several devices attached, any of which may need to influence the level, with no device owning either line.

Read the figure for what it does not contain. There is no arrow from a driver to a receiver, because the roles change. There is no per-device conductor, because that was the whole point of Module 1. And there is nothing yet showing how a level is produced — the figure draws the topology, and the mechanism is the next three chapters.

3. The Free Bus

The bus has a defined resting state, and it is the reference point every later behaviour is described against.

When no device is using the bus, both SDA and SCL are HIGH. That is the free, idle condition: no transfer is in progress and any participant may begin one. It is worth noticing that this is a convention with consequences rather than an arbitrary choice — a level that means "nobody is using this" has to be a level that every device can produce simultaneously without conflict, and by the end of this module you will see why HIGH is the only candidate.

A device that wants to convey something changes that. Bringing a line LOW is how a participant asserts itself on the bus, and returning it HIGH is how it stops. That single sentence is the entire behavioural vocabulary the wires have, and every protocol mechanism in the later modules is built from it.

The figure is deliberately unstructured. Real traffic has a beginning, an end and a grammar, and a reader who has seen a capture elsewhere will be tempted to read those into it. There is nothing there to read: the figure shows two conductors taking two levels, which is all the contract guarantees at this point.

4. A Device Observes the Bus, Not Its Own Output

One consequence of sharing is easy to state and easy to forget, and every later module depends on it.

On a dedicated output, a device's intent and the wire's state are the same fact. A block that drove HIGH knows the wire is HIGH; there is nothing else attached that could disagree. Designers stop distinguishing the two because the distinction never does any work.

On a shared rail those are two different quantities:

What this device is doing — its own intent, entirely under its control.

What the rail is actually at — the result of every participant's contribution together.

They can differ, and when they do it is not a fault. A participant may be contributing nothing while the rail sits LOW because somebody else is acting on it. The only way to know the rail's state is to read it — which is why every device on this bus has an input capability on both lines, not just an output.

5. RTL Connection — Naming the Two Quantities Correctly

That distinction has a direct consequence for how an I²C block's interface should be written, and getting it wrong at this stage produces a design that cannot be fixed later without reworking its boundary.

The instinctive interface treats each line as an ordinary signal:

   // A single output per line. This looks harmless and is not.
   module i2c_block_wrong (
       input  logic clk,
       input  logic rst_n,
       output logic sda_out,      // "the value I want on SDA"  <-- the mistake
       output logic scl_out
   );
   endmodule

sda_out encodes a level, which silently assumes this block decides what the level is. Two things it cannot express follow immediately: there is no way to say "I am not participating", and there is no way to find out what the rail actually did.

The interface that matches the hardware separates intent from observation, and splits intent into the only two things a participant on a shared rail can request:

   module i2c_block (
       input  logic clk,
       input  logic rst_n,
       // --- intent: what THIS participant requests, one bit per line ----------
       output logic sda_drive_low,   // 1 = pull SDA toward LOW; 0 = release it
       output logic scl_drive_low,   // 1 = pull SCL toward LOW; 0 = release it
       // --- observation: what the shared rail actually resolved to ------------
       input  logic sda_in,          // the rail's level, read back
       input  logic scl_in
   );
   endmodule

Four ports instead of two, and every one of them earns its place:

• sda_drive_low is a request, not a level. Its two states are pull and release — note that the release state is the absence of a request, not a second level being driven. Why a participant is limited to those two, and what the hardware behind them looks like, is Chapter 2.3.
• sda_in exists because the rail is shared. A block that cannot read the line back cannot detect that another participant is acting, cannot notice that a line it released has not risen, and cannot implement anything that depends on either.
• scl_in exists for the same reason, which is the concrete payoff of §2's claim that SCL is not a plain output. A design that omits scl_in has no way to observe the clock line, and two legal behaviours in later modules require exactly that.
• The names contain no 1. Nothing in this interface can express "drive HIGH", and that is deliberate.

These are interface sketches with no bodies — there is nothing to simulate yet, because nothing here decides when to pull or release. That behaviour needs the electrical model the next two chapters build, and Chapter 2.3 turns exactly this port list into executable, testbench-backed RTL in all three languages. What this chapter owes you is the port list itself, because a block whose boundary lies about the hardware cannot be rescued by its internals.

6. "Who May Drive" Is Not Yet Answerable

The purpose of this chapter is the contract, and the contract has a hole in it that is worth making explicit rather than papering over.

It is easy to say that a device "drives SDA LOW". It is much harder to say what happens when two devices attached to the same conductor make different decisions at the same instant — and nothing established so far rules that out. Every device is attached to both lines. Every device can influence both lines. Nothing in the topology arbitrates.

That is not a gap in the explanation; it is the actual engineering problem, and the reason this module exists. An ordinary digital output, of the kind used everywhere else in a design, cannot be attached to a shared node like this. Understanding exactly why is the subject of Chapter 2.2, and the fix that follows from it reshapes the output stage itself.

7. Common Misconceptions

8. Reason It Through

Work this through before reading the answers.

A designer sketches an I²C connection between a host and one peripheral. They assign SDA as an output of the host and an input of the peripheral, and SCL as an output of the host, reasoning that "the host is the one in charge."

What is wrong about SDA? The peripheral has to be able to convey information back — values read from it travel to the host on the same conductor. Making SDA a host output and a peripheral input removes the return path entirely: the host could address and write, and could never read.

What is wrong about SCL? Less obviously wrong, and wrong for two reasons that appear later. The initiating participant does normally source the timing, so the sketch would work for a while. But the specification permits an attached device to hold the clock line when it needs time, and in a system with a second potential initiator the line is shared rather than owned. A design that wires SCL as a plain output has no way to observe either situation.

Would the sketch work with exactly one peripheral that never needs time? Possibly — which is what makes the error durable. It can survive bring-up against a cooperative device and fail later against a different one, or against the same one under load. The contract is what the bus guarantees, not what one device happens to tolerate.

What has still not been established? How any of it works electrically. Nothing so far says how a level is produced or what happens if the host and the peripheral both act on SDA at the same instant. The sketch is wrong about direction; the rest of this module is about whether the arrangement is even safe.

9. Understanding Check

10. Summary

The bus is two shared conductors plus a common ground reference. SDA carries information one bit at a time; SCL carries the timing that says when a bit on SDA is meaningful.

Neither conductor belongs to a device. Both are shared nodes with several devices attached, every one of which has an output and an input capability on each line. SDA's direction of use changes within a transfer, and SCL — although normally sourced by the initiating participant — is also shared, because devices are permitted to influence it and later modules depend on exactly that.

A free bus is HIGH on both lines. A participant asserts itself by bringing a line LOW and stops by returning it HIGH, and that two-level vocabulary is everything the wires themselves provide.

What the contract does not supply is a mechanism. Nothing here says how a level is produced, how HIGH is restored, or what prevents two attached devices from disagreeing destructively — and the last of those is a real electrical problem, not a bookkeeping one.

11. What Comes Next

Chapter 2.2 builds the obvious implementation — an ordinary digital output of the kind used everywhere else in a design — attaches two of them to one conductor, and looks carefully at what the node actually does when they disagree. The failure is specific and instructive, and the rest of the module is the architecture that removes its possibility rather than managing it.

Browse the full path on the I²C tutorials index. For the argument that produced this two-conductor shape in the first place, see From Parallel Buses to Two Wires.