I2C Timing: Definition and Specification Guide (Part 2)


In this blog post, we will be discussing I2C timing specifications and the various ways manufacturers sometimes provide these specifications. For a primer on I2C and its protocols, please refer to the post here.

I2C data transfers occur over a physical two wire interface which consists of a unidirectional serial clock (SCL) and bidirectional data (SDA) line. These transfers can occur over speeds of 100kbits/s in Standard Mode, 400kbits/s in the Fast Mode, 1Mbits/s in Fast Mode Plus, and up to 3.4Mbits/s in High Speed Mode. Each data rate has its own timing specification that the master and slave must adhere to in order for correct data transfer. I2C compatible devices must be able to follow transfers at their own maximum bit rates, either by being able to transmit or receive data at the selected data rate. There are nuances such has setup and hold times for proper data transfer at a given data rate. We will be discussing these specifications in this blog post.

Figure 1, taken from the NXP “I2C-Bus specification and user manual”, depicts a timing diagram which provides definitions of the various timing specs for Fast Mode devices on the I2C bus. We will only use the Fast Mode timing diagram for our discussion as the majority of LTC I2C parts support this mode. However, the definitions discussed are also applicable to the other speed modes. We will also only discuss how these specifications apply to slave devices as Linear Technologies I2C compatible devices are typically slaves.

Figure 1: I2C Fast Mode Timing Definition

Rise (tr) and Fall (tf) Times

tr is defined as the amount of time taken by the rising edge to reach 70% amplitude from 30% amplitude for either SDA and SCL, while tf is defined as the amount of time taken by the falling edge to reach 30% amplitude from an amplitude of 70%.

Figure 2: Rise and Fall Time

Setup and Hold Times

Setup time is defined as the amount of time data must remain stable before it is sampled. This interval is typically between the rising SCL edge and SDA changing state. Hold time on the other hand is defined as the time interval after sampling has been initiated. This interval is typically between the falling SCL edge and SDA changing state. It is important that data be held stable during these intervals as failure to do so would result in data being sampled improperly.

In the I2C standard the minimum amount of time required in these intervals, which varies by the operating speed mode, is specified for both the START and STOP conditions as well as for data bits. I2C compatible slave devices are specified within these parameters to recognize incoming data.

Setup and Hold Time for Start Condition

Recall that the start condition is defined as when the SDA line goes LOW before SCL transitions LOW, i.e SDA transitions to a LOW state when the SCL line is HIGH.

Figure 3: Start and Stop Conditions

Hold Time For Start Condition (tHD;STA): is the minimum time the data should be low before SCL goes low. It is measured as the time taken from 30% amplitude of SDA from a HIGH to LOW transition to 70% of the amplitude of SCL from a HIGH to LOW transition.

Figure 4: Setup and Hold Time for (Repeated) Start Condition

Setup Time For a Start Condition (tSU;STA): is a timing specification that is only taken into account during a repeated start condition. It is the minimum time the SDA line is required to remain high before initiating a repeated start. This is measured as the time interval between 70% amplitude of SCL from a LOW to HIGH transition and 70% amplitude of SDA from a HIGH to LOW transition.

Setup for Stop Condition

In a stop condition SDA transitions to a HIGH state after the SCL transitions HIGH. See Figure 3. There is no hold time requirement for a stop condition, however a minimum setup time is still necessary.

Setup Time for Stop Condition (tSU;STO) is measured as the time between 70% amplitude of the rising edge of SCL and 30% amplitude of a rising SDA signal during a stop condition.

Figure 5: Setup Time for Stop Condition

Setup Time for Data (tSU;DAT)

Similarly there is a setup time for data which is defined as the minimum amount of time required for SDA to have reached a stable level before an SCL transition takes place. This is measured between 30% amplitude of SDA during a falling edge or 70% amplitude of SDA during a rising edge and 30% amplitude of SCL during a rising edge.

Figure 6: Setup Time of Data

Data Valid Time (tDV;DAT)

The validity of data is measured at every data and clock transition. The I2C specification states maximum allowed data valid times at different speeds. The data valid time tDV;DAT is measured between the falling edge of SDA at 30% or the rising edge of SDA at 70% amplitude with reference to 30% of the falling edge of SCL. There is also a separate Acknowledge valid time spec tDV;ACK which is measured similar to the data valid time, except it is measured only at the falling edge of the eighth clock bit. See Figure 1.

Buffer time (tBUFF)

Buffer time specifies the bus free time between stop and start conditions. This time period allows other devices on the bus to detect a free bus and attempt to transmit data. Slave devices often specify this as a minimum required bus free time. If a master – previously communicating with another device - attempts to address a slave device without letting the elapsed buffer time pass between its stop and start condition, the slave device may not be able to differentiate the new start condition as a separate transaction and might not respond.

Figure 7: Bus Free Time

Now that we have defined the various timing specifications, let’s see how they are specified by the I2C specification. See figure 8 which is taken from the NXP I2C user manual.

Figure 8: NXP I2C Timing Specification

The I2C specification table defines its parameters to allow IC designers to design their IC’s to be compatible with the bus requirements. As an example an IC compatible with Fast Mode I2C would be designed to recognize a start condition hold up time of at least 0.6µs. It could be designed to recognize a faster hold up time but at a bare minimum it should recognize timings of up to 0.6µs.

Taking this specification, manufacturers define the I2C compatibility of their IC’s in two ways. Examples of which are provided below.

Slave I2C Timing Specifications: Two Perspectives

The LTC2493 is a 24-Bit Delta Sigma ADC which specifies its I2C timing as follows:

Figure 9: LTC2493 I2C Timing Spec Table

While the LTC4261 which is a 48V Hot Swap controller specifies timing as shown below:

Figure 10: LTC4261 Timing Spec Table

Notice the discrepancy? Both devices have the same specifications but are presented in a different way, and while this can be a source of confusion it can be easily explained.

The LTC2493 timing spec table represents data from the viewpoint of the firmware designer, telling the designer exactly what to do. For example the set up time for a repeated start condition is specified as a minimum of 600ns, meaning the master needs to provide a pulse with a setup time of at least 600ns. This is a copy of the I2C specification and is instructing the firmware engineer what the timing of the signals should be.

The LTC4261, on the other hand, represents data from the viewpoint of the IC itself, telling the firmware designer what the IC itself is capable of. For example, the minimum setup time for a repeated start condition is defined as a typical number of 30ns and a maximum of 600n, meaning that the LTC4261 guarantees that the minimum setup time is no longer than 600ns (thus it meets the 600ns required minimum of the spec), in fact it can recognize setup time intervals down to 30ns, allowing for greater margin in timing.

Thus timing specifications can be presented differently even though they depict the same data. In the case of the two examples above, both parts are consistent with the I2C standard and adhere to I2C timing requirements.

Об авторах

Hamza (Sal) Afzal

Sal Afzal

Sal Afzal is the Applications Engineering Director of the Power Systems Management group at Analog Devices. Sal has a bachelor’s in electrical engineering from San Jose State University. He has designed hardware for a broad variety of markets including data center, automotive and industrial. He specializes in power protection and power path control.