5
\$\begingroup\$

In I2C protocol one data bit is transferred during each clock pulse of the SCL. All the SCL-SDA timing diagrams I've encountered so far are shown as below:

enter image description here

My problem is that instead of one bit of data is sent following a clock rising edge, above we see that the clock rising edge comes after one bit of data. If we look at the very left for instance, we see that MSB is created before the clock.

This makes me super confused, since the clock supposed to be used to sync the data bit transfer yet in this case it seems it lags the data. Can someone clarify the relationship between clock and data bits?

Here another example where, again, the data bit occurs before the clock:

https://electropeak.com/learn/wp-content/uploads/2021/08/Multiple-I2C-4.jpg

\$\endgroup\$
0

4 Answers 4

Reset to default
5
\$\begingroup\$

I think you're confusing transmitter and receiver.

The transmitter obviously has to set up the data ahead of time, so that the receiver can read it correctly.

Therefore, it must take a few extra cycles (of its own internal timing clock) to do that.

The receiver only* pays attention to the value of SDA, at SCL rising. So SDA must be stable ahead of time, and that's when the transmitter sets the value, then releases its SCL (and hopefully no others holding it low; clock stretching is, I think, fairly rare among devices?).

There is no contradiction, because the receiver counts rising edges, and receives the, whatever the packet is for, 16, 24, etc. edges. The transmitter must send data leading clock, but the clock rising must lag after data-stable.

*Aside from the special symbols, where SCL and SDA rise out-of-order, signalling the start or end of a packet.

\$\endgroup\$
7
  • \$\begingroup\$ During the high period of the clock SCL, will the receiver sample the data bit with a higher freq than SCL clock freq.? In other words, does SCL on time is the sampling interval for the receiver? \$\endgroup\$
    – user1245
    Jul 7, 2022 at 11:40
  • \$\begingroup\$ @user1245 It's rising-edge triggered, not level triggered. (Actual implementations may vary; the level can be sampled as often as you want, as long as it behaves per the specifications. See: nxp.com/docs/en/user-guide/UM10204.pdf ) \$\endgroup\$
    – Tim Williams
    Jul 7, 2022 at 12:46
  • \$\begingroup\$ It's rising-edge triggered, not level triggered Actually, UM10204 specifies I2C data transfer wrt SCL level - nowhere does it refer to SCL edges. It's a valid but subsequent deduction that the a receiver can take SDA data bits as/before SCL rises. \$\endgroup\$
    – TonyM
    Jul 7, 2022 at 12:51
  • \$\begingroup\$ @TonyM I admit it's been a while since I looked at I2C in great detail. I don't have time to dig into the standard right now; offhand, I see: "The data on the USDA line must be stable during the HIGH period of the clock. The HIGH or LOW state of the data line can only change when the clock signal on the USCL line is LOW", which makes edge/level ambiguous (but certainly makes sampling SDA with SCL low, a bad idea). \$\endgroup\$
    – Tim Williams
    Jul 7, 2022 at 12:58
  • 1
    \$\begingroup\$ Yep, you've outlined it correctly, I was just clarifying that the spec' doesn't spell this stuff out like it should. It has to be deduced, unfortunately. \$\endgroup\$
    – TonyM
    Jul 7, 2022 at 13:33
4
\$\begingroup\$

The diagram is correct.

In any general method of data transmission, the data line must be stable for some period of time before the active clock edge, and data line must be stable for some period after the active clock edge.

With I2C, it just has a requirement, that during data transmission, the data line can change only while clock is low.

That's because if data line changes when clock is high, those are the start and stop conditions.

So in I2C, data line must be set some time before rising clock edge, and it must be kept stable well after falling clock edge too.

You can read the I2C specification or application notes about it.

\$\endgroup\$
4
  • \$\begingroup\$ Small correction - "In any synchronus general method of data transmission" - there are many different types of data transmission, and a lot of them dont use a clock signal, whether because they use an internal clock, or they use some other type of scheme that doesnt involve any type of clock \$\endgroup\$
    – BeB00
    Jul 7, 2022 at 10:02
  • \$\begingroup\$ @BeB00 it is an universal problem, not just a synchronous data transmission problem. Even if you have an asynchronous data transfer method like UART, you will still use a local clock for sampling the data line, and, just like with a simple D flip flop, the data line needs to be stable for the set-up period before clock edge and for the hold time after clock edge, or the output of D flip flop behaves erratically and has a chance of error. Which is why FPGA designs and MCU data pins have synchronizers. \$\endgroup\$
    – Justme
    Jul 7, 2022 at 10:42
  • \$\begingroup\$ @Justme During the high period of the clock SCL, will the receiver sample the data bit with a higher freq than SCL clock freq.? In other words, does SCL on time is the sampling interval for the receiver? \$\endgroup\$
    – user1245
    Jul 7, 2022 at 11:40
  • 1
    \$\begingroup\$ @user1245 Different devices can implement the bus differently as long as it works. But yes a MCU could sample 100 kHz bus at 1 MHz or even faster. Another chip might simply implement a state machine based on bus wire transitions. \$\endgroup\$
    – Justme
    Jul 7, 2022 at 11:58
2
\$\begingroup\$

The I2C bus is defined in the current I2C spec'. However, the bit behaviour of a transmitter and receiver bit behaviour is not all stated directly and has be somewhat deduced from it in a few places.

As shown in your diagram, during bit transfer then data line SDA must be steady while clock SCL is high. The current bus driver must change SDA while SCL is low.

There's some stuff outside of the bit transfer phases, around START and STOP conditions, that affects those rules and needs observing.

From all that, there's three bus activities an I2C bus target device needs to detect and act on:

  • START and STOP conditions
  • SCL rising edges: for shifting in data bits and ACK bits
  • SCL falling edges: for shifting out data bits and ACK bits

An I2C bus master is more complicated than that but follows the same bit transfer rules.

I've previously designed I2C bus masters and targets in VHDL and have trawled through the spec' in detail. It'd be nice if it was more outright on this and a couple of other things, one being the SCL/SDA behaviour between ACK and STOP.

\$\endgroup\$
0
\$\begingroup\$

Your observation that the clock "lags" the data is actually pretty much what's going on and is intentional. On all digital busses, data needs to be valid during a specified clock sub-period (for I2C, which has a dedicated clock signal, this is defined by the spec as during SCL's high state; practically speaking, most I2C devices sample just after the rising edge of SCL.) We would like to have data be valid the first time this clock sub-period happens, because anything else would be wasting precious time. Therefore, clock "lags" data - data is set up before the first read-valid clock pulse.

I2C accomplishes the task of getting data set up before the first clock pulse by having the SCL transmitter and SDA transmitter always be the same device at the beginning of a transaction - it knows when the clock is coming in the same way your right hand knows what your left hand is doing. When the clock and data transmitters are different, it is always further into a transaction, when the data transmitter can use the falling edge of the previous clock to know when it's time for it to drive SDA.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.