I2C (Inter-Integrated Circuit) Design and Validation Step-by-Step Guide

There is a wide variety of serial interfaces, whose purpose is to provide a means of communication between integrated circuits, or even a separate electronic module. We already discussed one of them – UART, in one of our previous blogs. Another example is I2C (stands for Inter-Integrated Circuit).

What Is I2C?

I2C specification is invented in 1982 by Philips Semiconductors. This interface is mainly aimed at communication among the integrated circuits located on the same PCB (originally not meant to go via an external cable). This limitation is due to a low communication robustness if combined with a higher data rate. Of course, this does not mean that it is impossible to use it for external parts of the system, as we will discuss.

Why would we want to use I2C? Because it is simple, requires only two signal lines (besides VCC and GND), and enables communication between one master and possibly multiple slave devices. Newer revisions of the I2C specification support the arbitration process, which enables multiple masters on the same bus, but this may be the topic of one of our next blogs. Anyway, having multiple nodes on the same bus is perfectly safe (even in case the system malfunctions). We can thank that to an open drain driver of all nodes. In other words, nodes can only drive the logical ‘low’ state on the bus. A logical ‘high’ state is obtained by the inactive state of all drivers on the bus and pullup resistors (R on block diagram below) on SCL and SDA lines.

As a result, even if the system malfunctions, the short-circuit state cannot occur since all drivers drive the same state (or don’t drive at all). To conclude, we can refer to the ‘low’ as a dominant and ‘high’ as a recessive state of the bus.

Another benefit of synchronous communication buses in general is that they are (as the name implies) synchronized to their clock signal. In other words, the clock is a reference of its own, no matter how accurate or not it is.

How To Properly Design an I2C Communication Bus?

The drawback of the open drain topology is its speed. Each IC and PCB trace (or cable wiring) adds some parasitic capacitance (approximately 3-5 pF per IC pin and approximately 1-4 pF for regular size PCB trace). If the communication goes via an external cable, this can grow up to 200 pF per cable meter (that’s one of the reasons why I2C isn’t meant to go through the cable).

Referring to the block diagram above, we can notice the RC time constant that needs to be filled for the bus to gain the ‘high’ logic state (C being the parasitic capacitance and R being the pullup resistors). To gain more speed (faster rise time of the bus), R can be decreased. But this results in higher power consumption (i.e. higher current that the IC pin needs to sink while it drives the low state). This represents the lower limit for the R-value in the I2C system design. If we are designing a low consumption battery powered device, we will want to minimize the power draw, so we will want to increase the R-value as much as possible. Obviously, the desired I2C speed will set the upper limit for the R-value. In practice, the most common R values are in the range of 1 to 47k Ohms.

What To Test and Verify in I2C Communication System?

As you may have noticed by now, the pullup resistor value (R) is the main aspect of I2C system design. This is also the easiest thing that we can change once we manufacture the prototype devices (considering the PCB is fixed, as well as the eventual cabling system). Under the assumption that the rest of the system is designed properly (valid voltage rails and logic voltage levels for all ICs), the main thing that needs to be validated in the I2C system is the bus rise time.

First, we need to establish the system requirements – what kind of sampling frequency is required from the I2C sensors, or what is a general requirement for the data rate of the I2C bus? This will determine the required clock frequency. So, we need to determine whether we fall in Fast-mode (400 kbit/s) and faster category. If not, hopefully, the Standard-mode (up to 100kbit/s) will suffice.

One of our designs that we will use as a reference in this blog was an I2C system with one bus master and two bus slaves. The slaves were environmental sensors and luckily, we were satisfied with the Standard mode I2C bus (note that Standard mode supports up to 100 kbit/s, and complete I2C bus specification allows for any arbitrary clock frequency from 0 to 100 kHz; as the clock signal is a reference to any synchronous communication interface).

Anyway, back to our design. The sensors were placed on a remote PCB connected with several meters long cable. Now, this application is not something that can utilize I2C by default as I2C is meant to be on-board communication interface primarily. However, a good engineer always needs to know what the limitations are, why and how to measure it.

We went towards the design of prototypes with having a cabling in mind (considering the length of a cable, we are looking at appr. 1-2 nF of capacitance), so we anticipated I2C bus buffers. However, even with buffers, the bus oscillogram looked like this.

From the above oscillogram, we can observe the signal can barely reach the ‘high’ level. In practice, this resulted in failing communication. From this point on, there were several attack strategies:

• Decrease the pullup resistors value – this method would decrease the rise time, but also increase the stress on IC pins (sink current) and overall power consumption
• Decrease the SCL frequency – the only drawback of this method is reduced data rate, for which we concluded it is OK, as we don’t expect a high amount of traffic on this bus.

We decided to continue with the decrease of SCL frequency. As mentioned earlier, in synchronous communication systems, the clock signal is a reference. In other words, we can freely choose the frequency and everything else will adapt correspondingly.

Once we lowered the frequency from 100 to 40 kHz, the oscillograms looked as below.

Yellow oscillogram represents the SCL signal and green represents the SDA signal. What we can observe in this oscillogram:

• Rise time is now satisfactory, and all signals look well.
• We can see a capacitive crosstalk between SCL and SDA line. This is visible during the SCL transition periods (as the coupling mechanism is AC due to its capacitive nature). We can see that yellow trace (SCL) is aggressor and the green trace (SDA) is the one which receives the interference. This is a result of strong capacitive coupling between SC and SDA (remember we are going through several meters of a cable). If this proves to be a problem, we can mitigate this with a different cable structure – possibly twisted pairs where SDA and SCL would separately be twisted with a current return path – VSS.

Conclusion

I2C stands as a widely employed communication interface, particularly favored for linking sensors, port expanders, and peripheral ICs. Its efficiency lies in its ability to conserve pins, needing just two for operation, while accommodating multiple slaves on a single bus.

Yet, despite its popularity, I2C isn’t without limitations. Factors such as data rate and distance constraints pose challenges. However, armed with a deep understanding of its workings and underlying requirements, we can refine our designs to ensure optimal performance for our applications.