IC Design : I2C

I2C is a serial communication protocol. It provides good support to the slow devices, for example, EEPROM, ADC, I2C LCD, and RTC etc. It is not only used with the single board but also used with the other external components which have connected with boards through the cables.

I2C is basically a two-wire communication protocol. It uses only two wire for communication. In which one wire is used for the data (SDA) and other wire is used for the clock (SCL).In I2C, both buses are bidirectional, which means master able to send and receive the data from the slave. The clock bus is controlled by the master but in some situations slave is also able to suppress the clock signal.

Additionally, an I2C bus is used in the various control architecture, for example, SMBus (System Management Bus), PMBus (Power Management Bus), IPMI (Intelligent Platform Management Interface) etc.

Physical I²C Bus

I2C Bus (Interface wires) consists of just two wires and are named as Serial Clock Line (SCL) and Serial Data Line (SDA). The data to be transferred is sent through the SDA wire and is synchronized with the clock signal from SCL. All the devices/ICs on the I2C network are connected to the same SCL and SDA

Both the I2C bus lines (SDA, SCL) are operated as open drain drivers. It means that any device/IC on the I2C network can drive SDA and SCL low, but they cannot drive them high. So, a pull up resistor is used for each bus line, to keep them high (at positive voltage) by default. The reason for using an open-drain system is that there will be no chances of shorting, which might happen when one device tries to pull the line high and some other device tries to pull the line low.

Master and Slave Devices

The devices connected to the I²C bus are categorized as either masters or slaves. At any instant of time only a single master stays active on the I²C bus. It controls the SCL clock line and decides what operation is to be done on the SDA data line.

All the devices that respond to instructions from this master device are slaves. For differentiating between multiple slave devices connected to the same I²C bus, each slave device is physically assigned a permanent 7-bit address.

When a master device wants to transfer data to or from a slave device, it specifies this particular slave device address on the SDA line and then proceeds with the transfer. So effectively communication takes place between the master device and a particular slave device.

All the other slave devices doesn’t respond unless their address is specified by the master device on the SDA line.

Data Transfer Protocol

The following protocol (set of rules) is followed by master device and slave devices for the transfer of data between them.

Data is transferred between the master device and slave devices through a single SDA data line, via patterned sequences of 0’s and 1’s (bits). Each sequence of 0’s and 1’s is termed as a transaction

Start Condition

Whenever a master device/IC decides to start a transaction, it switches the SDA line from high voltage level to a low voltage level before the SCL line switches from high to low.

Once a start condition is sent by the master device, all the slave devices get active even if they are in sleep mode, and wait for the address bits.

Address Block

It comprises of 7 bits and are filled with the address of slave device to/from which the master device needs send/receive data. All the slave devices on the I2C bus compare these address bits with their address.

Read/Write Bit

This bit specifies the direction of data transfer. If the master device/IC need to send data to a slave device, this bit is set to ‘0’. If the master IC needs to receive data from the slave device, it is set to ‘1’.

ACK/NACK Bit

It stands for Acknowledged/Not-Acknowledged bit. If the physical address of any slave device coincides with the address broadcasted by the master device, the value of this bit is set to ‘0’ by the slave device. Otherwise it remains at logic ‘1’ (default).

Data Block

It comprises of 8 bits and they are set by the sender, with the data bits it needs to transfer to the receiver. This block is followed by an ACK/NACK bit and is set to ‘0’ by the receiver if it successfully receives data. Otherwise it stays at logic ‘1’.

This combination of data block followed by ACK/NACK bit is repeated until the data is completely transferred.

Stop Condition

After required data blocks are transferred through the SDA line, the master device switches the SDA line from low voltage level to high voltage level before the SCL line switches from high to low.

NOTE: Logic ‘0’ or setting a bit to ‘0’ is equivalent to applying low voltage on the SDA line and vice versa.

How I2C Communication Practically Works?

An I2C communication/transaction is initiated by a master device either to send data to a slave device or to receive data from it. Let us learn about working of both the scenarios in detail.

Sending Data to a Slave Device

The following sequence of operations take place when a master device tries to send data to a particular slave device through I2C bus:

The master device sends the start condition

The master device sends the 7 address bits which corresponds to the slave device to be targeted

The master device sets the Read/Write bit to ‘0’, which signifies a write

Now two scenarios are possible:

If no slave device matches with the address sent by the master device, the next ACK/NACK bit stays at ‘1’ (default). This signals the master device that the slave device identification is unsuccessful. The master clock will end the current transaction by sending a Stop condition or a new Start condition

If a slave device exists with the same address as the one specified by the master device, the slave device sets the ACK/NACK bit to ‘0’, which signals the master device that a slave device is successfully targeted

If a slave device is successfully targeted, the master device now sends 8 bits of data which is only considered and received by the targeted slave device. This data means nothing to the remaining slave devices

If the data is successfully received by the slave device, it sets the ACK/NACK bit to ‘0’, which signals the master device to continue

The previous two steps are repeated until all the data is transferred

After all the data is sent to the slave device, the master device sends the Stop condition which signals all the slave devices that the current transaction has ended

Reading Data from a Slave Device

The sequence of operations remain the same as in previous scenario except for the following:

The master device sets the Read/Write bit to ‘1’ instead of ‘0’ which signals the targeted slave device that the master device is expecting data from it

The 8 bits corresponding to the data block are sent by the slave device and the ACK/NACK bit is set by the master device

Once the required data is received by the master device, it sends a NACK bit. Then the slave device stops sending data and releases the SDA line

If the master device to read data from specific internal location of a slave device, it first sends the location data to the slave device using the steps in previous scenario. It then starts the process of reading data with a repeated start condition.

Concept of clock stretching

Let say the master device started a transaction and sent address bits of a particular slave device followed by a Read bit of ‘1’. The specific slave device needs to send an ACK bit, immediately followed by data.

But if the slave device needs some time to fetch and send data to master device, during this gap, the master device will think that the slave device is sending some data.

To prevent this, the slave device holds the SCL clock line low until it is ready to transfer data bits. By doing this, the slave device signals the master device to wait for data bits until the clock line is released.

That’s it for this article. Take a look at the below projects to get an idea on how I2C communication is practically implemented, between microcontrollers and different sensors

I²C pros/SPI cons

I2C needs fewer connections: only 2 signal wires needed, versus 3+n for SPI where n is the number of slave devices that need SSEL or CS lines (i.e. on SPI, if you have five devices, you need 3+5 lines).

I2C uses chip addressing, which means that there is no need for SSEL/CS lines (same as above), and I2C devices can easily be added to the bus. To add a device to an SPI bus, you would need to add an extra SSEL/CS line, and you would need to know exactly which SSEL/CS lines are connected to which devices.

I2C uses an open collector bus, which allows some flexibility in bus voltage (in many cases, but not all cases, 3.3V and 5V logic devices can be mixed). On SPI, the bus voltage must be whatever is supported by all devices.

I2C is multi-master. It is possible for multiple devices on the bus to be the master device, and also to switch a device between master and slave device (if supported), without needing to change the wiring. On SPI, the master/slave relationships are fixed by the wiring.

Questions:

·
Be ready with the complete understanding of the specification and the working of I2C.

·
Different modes of operation for I2C and also the concept of Start and Stop condition.

·
Different addressing modes and what are the differences among them.

·
Complete process of Data Transfer on I2C bus.

·
Concepts of Arbitration

· Clock Stretching

· Clock Synchronisation are highly important.

·
What is the use of General call address and when it is being called.

·
If the intended address doesn't reach the slave what is the condition for that.

·
High impedance state occurred when?

·
You should have a good idea related to all the waveforms.

·
Differences between I2C and SPI and what to use when.

·
Coding based:

Can ask to write a code of BFM in SV/UVM.

How you take care of bidirectional signals in I2C.

If you have done any VIP developement related to I2C,you should have a good grasp on all the UVC.

A condition can be given and may be you need to write assertion for that.

All the above mentioned questions are my general thoughts and the list of questions could be endless.

It is always better,when you study any protocol or IP,be have a complete idea about it's working and specifically provide more focus on waveform understanding.

How does open collector work in I²C?

By making the clock and data lines in I2C open collector, the bus is weakly pulled up to Vcc, but any device on the bus can pull a line down to ground (strongly) and then all devices sharing the bus will see that the line is grounded. This isn't possible with single-ended push-pull logic where there can't be multiple devices driving the line simultaneously.

I2C protocol provides for an ACK/NAK signal at the end of every byte that takes advantage of this capability, any device can signal that it hears the command (or a data byte) correctly by pulling the data bus low. If it continues to float high, nobody was listening, which is a NAK.

Why does the I²C interface use an open-collector/open-drain output given that it slows down the throughput and requires a pull-up resistor?

Wired synchronous serial communication between 2 devices requires a clock signal (else it wouldn’t be synchronous). So that’s one line taken already (SCL). you need some line(s) for sending data. The most direct way is to have one line for sending bits, and another for receiving bits.

Another option is to somehow use the same line for sending and receiving, somehow deducing when the line is in use to avoid collisions and other stuff,
but as a plus, you’re using only 1 line (not 2) to send data both ways. SPI went with the first option, I2C went with the second (SDA).

To prevent the possibility of electrical contention on the line (that is, both parties trying to send data, driving the line at the same time),that can result in damaging currents (let alone, data corruption), open-drain/collector outputs are used for this data line, pulled HIGH through an appropriately-sized resistor. This way, the line can only be pulled LOW by any party, no damage can result of both devices trying to speak at the same time and any such collisions can be resolved relatively easily via arbitration in software (if it even needs to be handled at all). This also provides a way to detect when the line is in use (line is LOW, means someone is pulling it LOW).

You might then ask why the clock line is also open-collector and pulled high.Well, the I2C protocol permits multiple masters on the bus and since it’s usually the master who generates the clock,

It means you could have multiple parties trying to drive the clock line and thus cause the aforementioned contention. Also, slaves are allowed to pull the clock line LOW when they absolutely need to, perhaps to delay a response; this is called clock stretching.

So, since practically anybody can drive the line LOW when they please, the SCL line gets the same treatment as the SDA line.

It allow the bus to form a wired-AND without additional logic.The wired-AND logic function as arbitrator that decide which node own the bus for specific time slot.SPI interface use individual CS pin for each slaves, and thus the amount of pin used in the bus increase with the amount of slave.

While I2C only need 2 signal line for whatever amount of slaves (limited by bus capacitance).
The I2C bus has a single clock line and a single data line.

What is locking (or waiting) and unlocking the I2c protocol? How you could design the unlocking I2c protocol for your system.

In some circumstances the I2C bus can “lock up” in a busy state which prevents the master from ever being able to start a new transaction. Since the master controls the transactions on the bus, this means nothing else can happen after the lock-up occurs. Obviously, this could be a show-stopping condition for any system that depends on the I2C bus to scan sensors or read from EEPROM, for example.

To understand how the I2C bus can lock up, it’s helpful to think of things from the perspective of a slave device. The slave must monitor the state of the clock and data signals, and in particular must look out for transitions of either signal which may indicate the start or end of a transaction or the need to clock data in and out. All will be well provided the slave device sees the same series of transitions that the master generates, assuming they conform to the I2C protocol specification.

But if there’s some noise or interference that causes an unwanted extra transition or masks a wanted transition, the slave can get out of step with the master. For example, if the master needs to transfer one byte of data from the slave, the slave is expecting to see a specific number of transitions on the clock signal to clock each bit of the data out (and to provide an acknowledge signal). If a clock edge gets “lost” somehow, the slave device will never finish transferring the data and may end up continuously pulling the data line to an active low state.

Now the master might “think” that the transaction has finished, so won’t issue any more clocks, but the slave “thinks” the transaction is still in progress so will keep the bus in a busy state. While the bus is busy, the master can’t generate any more clock transitions. While there are no clock transitions from the master, the slave won’t let go of the bus.

Another situation where lock-ups might occur is during start-up when i/o signals from the master might have glitches or other unexpected transitions before they are stable. If an I2C slave device is monitoring the bus before the master brings the clock and data lines into the right (passive) state, this can cause the I2C bus to be locked before the master starts the first transaction.

Finally, even if the bus is very well-behaved and doesn’t suffer from noise or glitches, lock-up can occur during software development.

Testing and debugging a system using I2C and your software crashes or hits a breakpoint while an I2C transaction is in mid-flight.

If simply reset the CPU or re-start the software, the I2C slave will never see the end of that transaction so the I2C bus will be locked when the software re-starts.

How should my design handle lock-up?

So, I2C lock-up is definitely “a thing” in practice as well as theory. What can be done about it?

The first approach is prevention. This largely depends on good electronic design to minimise the chance of noise and glitches. For example, this might include:

using “strong” pull-ups to speed up the rising edge of the SCL and SDA signals

using i/o signals on the I2C master that have default “high” state, possibly with pull-ups, when the master comes out of reset

Software can sometimes also play a role: if the software running on the master has to configure the signals used by the I2C interface, be careful to make sure that the configuration sequence can’t introduce any unwanted transitions.

Despite the best intentions to prevent lock-up, it’s good practice when designing a system based on I2C to assume that lock-up can occur and to make the system resilient by detecting and recovering from it. This is usually a burden placed on the master software, although hardware design can also help out.

The basic principles here are:

Always implement a well-defined time-out period when waiting for any I2C event

If a time-out occurs that might indicate a lock-up, either reset all the slave devices or issue a sequence of at least ten clock cycles on the I2C SCL signal

All production-quality I2C device drivers should support time-outs when waiting for I2C events such as gaining access to the bus and completion of data transfers. Depending on the design, the I2C master may include a dedicated controller that might have hardware support for time-outs, in which case the driver should use it. Otherwise, or if the master uses “bit-banged” discrete input/output signals to drive the I2C interface, the I2C driver might have to use software time-outs. Either way, if a time-out occurs it could mean that the I2C bus has locked up and some recovery action needs to be taken. (One exception to this is if you’re dynamically “probing” the I2C bus to discover what devices are on it, but that is not very typical in production software for an embedded system.)

The best recovery action will also depend on the hardware design. In the best case, the hardware will allow each I2C slave device to be reset by the software on the master. For example, this could be done by toggling one or more discrete output signals. Otherwise, the best recovery action is usually to force a series of at least ten clock pulses out on the I2C clock signal. Why ten pulses? Because typically it takes nine clock pulses to clock one data byte in or out of a slave device, after which it will normally release the bus.

If the hardware has a dedicated I2C controller, generating this sequence of pulses might not be straightforward because the controller hardware might not give you direct access to drive the clock signal. In that case, you may have to re-configure the I2C clock pin so that it can be driven as a bit-banged discrete output. In any case, make sure that the clock pulses are generated at about the right frequency (e.g. 100 kHz or 400 kHz), and definitely no faster than the maximum clock rate of any device on the bus.

When the I2C Master initiates a transaction, it does so by asserting the CLK line and driving (clocking) '1's and '0's on the DAT line.

That's fine when the Master is sending data, or sending the address of the device it is trying to read from.
But there is some point where the Master must let the DAT line float to a high state and allow the slave device to drive the DAT line for the Master to read as it continues to drive the CLK line.
So the DAT line needs to be able to "float high" to allow any of several devices (including the Master) to drive the DAT line when it is supposed to.Similarly, the CLK line also has a pull-up resistor, because the I2C bus allows for more than one Master to be active, so more than one device might need to drive the CLK line also. There are provisions about how several Masters on the same I2C bus can talk and listen without interfering with each other.

There are more details, but that's the basic idea... low bit-rate communications between and among a lot of different devices with only 2 wires connecting them all.

What does I2C stand for?

Inter-Integrated Circuit

How many wires are required for I2C communication?

In I2C only two buses are required for the communication, the serial data bus (SDA) and serial clock bus (SCL).

I2C is half-duplex or full-duplex?

half-duplex

I2C is Synchronous or Asynchronous Communication?

I2C is Synchronous Communication

Explain the physical layer of the I2C protocol

I2C is pure master and slave communication protocol, it can be the multi-master or multi-slave but we generally see a single master in I2C communication. In I2C only two-wire are used for communication, one is data bus (SDA) and the second one is the clock bus (CLK).

Wire-AND configuration

All slave and master are connected with same data and clock bus, here important thing is to remember these buses are connected to each other using the WIRE-AND configuration which is done by to putting both pins is open drain. The wire-AND configuration allows in I2C to connect multiple nodes to the bus without any short circuits from signal contention.

The open-drain allows the master and slave to drive the line low and release to high impedance state. So in that situation, when master and slave release the bus, need a pull resistor to pull the line high. The value of the pull-up resistor is very important as per the perspective of the design of the I2C system because the incorrect value of the pull-up resistor can lead to signal loss.

Note: We know that I2c communication protocol supports multiple masters and multiple slaves, but most system designs include only one master.

Explain the operation and frame of I2C protocol

I2C is a chip to chip communication protocol. In I2C, communication is always started by the master. When the master wants to communicate with slave then he asserts a start bit followed by the slave address with read/write bit.

After asserting the start bit, all slave comes in the attentive mode. If the transmitted address match with any of the slave on the bus then an ACKNOWLEDGEMENT (ACK) bit is sent by the slave to the master.

After getting the ACK bit, master starts the communication. If there is no slave whose address match with the transmitted address then master received a NOT-ACKNOWLEDGEMENT (NACK) bit, in that situation either master assert the stop bit to stop the communication or assert a repeated start bit on the line for new communication. When we send or receive the bytes in i2c, we always get a NACK bit or ACK bit after each byte of the data is transferred during the communication.

In I2C, one bit is always transmitted on every clock. A byte which is transmitted in I2C could be an address of the device, the address of register or data which is written to or read from the slave.

In I2C, SDA line is always stable during the high clock phase except for the start condition, stop condition and repeated start condition. The SDA line only changes their state during the low clock phase.

What is the role of the shift register in Master and Slave devices in SPI?

In SPI, shift register are used. Here data is transferring to the slave using the MOSI bus and at the same time receiving the dummy data from the MISO bus and vice versa. Every writes there is dummy read and every read there is dummy write.

Does SPI slave acknowledge the receipt of data?

Nope, SPI doesn’t give any ACK like I2C.

SPI has a higher throughput than I2C – True / False?

SPI is faster than I2C.

Is SPI support duplex communication?

Yes.

Why use SPI?

Unlike the serial com port, SPI is the synchronous communication protocol. In SPI master and slave both shared the same clock and clock is produced by the master. In the case of asynchronous serial communication, every byte consists of a start and stop bits which create extra overhead on communication.

Another disadvantage of serial com port communication is that it needs to maintain clock frequency of the transmitter and receiver ( both not shared the clock). If the frequency of the transmitter and receiver does not match then the receiver will not receive the data transmitted by the transmitter.

SPI is Synchronous or Asynchronous Communication?

SPI is Synchronous Communication.

What is SPI communication ?

Serial peripheral communication.. the data will transfer from master to slave serially i.e is bit by bit serially using shift registers(SISO).

How many wires are required for SPI communication ?

SPI is 4 wired Communication – MOSI , MISO, SCK and nCS.

What are the 4 logic signals specified by SPI bus ?

1.MOSI : Master Out Slave IN 2. MISO : Master IN Slave Out. 3. SCK : Serail Clock 4. nCS : Chip Select

Does SPI slave acknowledge the receipt of data ?

Nope, SPI doesn’t give any ACK like I2C.

SPI has higher throughput than I2C – True / False ?

SPI is faster than I2C . Bit rates of I2C is 100 kbps and for SPI 1 Mbps.

Duplex communication is possible by simultaneously using MOSI and MISO during each SPI clock cycle – True / False ?

True, because MOSI line to transfer the data to slave and mean while MISO line receive the data from slave

Is it possible to connect SPI slaves in daisy chain ?

Yes, possible using “daisy chain” concept we can reduce the number of GPIO pins.

What is the role of shift register in Master and Slave devices in SPI ?

In SPI, SISO shift register are used. Here data is transferring to save using MOSI bus and at the same time receiving the dummy data from MISO bus and vice versa. Every write there is dummy read and every read there is dummy write.

How will the master convey that it is stopping the transmission of data ?

using Chip select (GPIO) pin. When ever chip select pin is pulled to HIGH then data can not be transferred.

Does start-stop bit support by SPI?

No.

Does pullup register require in SPI?

No.

Does bus arbitration support by SPI?

No.

Does the clock stretching support by SPI?

No.

What is the difference between SPI and I2C (I2C vs SPI)?

You can see this article, Difference between I2c and SPI

What are the advantages of the SPI communication protocol?

There is no start and stop bits, so the data can be streamed continuously without interruption.
It supports full-duplex.
No need for precision oscillators in slave devices as it uses a master’s clock.
No complicated slave addressing system like I²C.
Higher data transfer rate than I2C (almost twice as fast).
Separate MISO and MOSI lines, so data can be sent and received at the same time.
Simple software implementation.

What are the disadvantages of the SPI communication protocol?

If there is more than one slave in communication then the wiring will be complex.
Uses four wires (I2C and UARTs use two).
No acknowledgment that the data has been successfully received (I2C has this).
No form of error checking like the parity bit in UART.
It only allows for a single master.

Can devices be added and removed while the system is running (Hot swapping) in I2C and SPI?

Hot swapping is possible in I2C protocol.

What is the maximum speed of operating frequency can be used with SPI?

How would you set its clock for your application?

How many wires are used for SPI?

How addressing of slaves is achieved?

Which company pioneered SPI?

Practical examples of SPI devices

Why spi? Comparison with i2c and other communication protocols.

Spi basics like is it multi master communication protocol? Speed, half/full duplex etc.

Application where you used it previously, how you debug it? Like waveforms observed (use of tools like DSO). Explanation with waveforms.

Necessity of chip select pin? For single slave whether it is must.