# What is the I2C ACK, and how do I detect it?

I am writing an FPGA driver in Verilog for a temperature sensor (datasheet available here). The communication protocol is SMBus, a close cousin of I2C. Now reading the datasheet, I understand that the ACK signal is composed of two parts (see page 10, figure 5):

1. First, SDA is driven low on the 9th clock cycle
2. Then, SDA is "spiked" (driven high, then immediately driven low) between the 9th and 1st clock cycles

This seems to contradict this tutorial where it is claimed that an ACK is simply done by driving SDA low (no "spike" is mentioned).

Is this "spike" actually included in the ACK signal? If so, how should I detect the "spike"?

• Take a look at this file under section 6.2. That seems to be the specification of the I2C – AndrejaKo Apr 11 '12 at 9:56
• @AndrejaKo: Thanks but from my perspective, the link is dead. – Randomblue Apr 11 '12 at 10:01
• @AndrejaKo - That's an old (1995!) document. The most recent version of the spec, February 2012, is here – stevenvh Apr 11 '12 at 10:08
• IIC ACK is effectively a violation of the IIC data transfer protocol which is used to signal receipt of a completed data block. Any spike is incidental. As long as you follow the instructions and meet timing requirements, when other signals rise or fall (to generate what might be seen as "spikes" is of no relevance. Note that 'dricven high then immediately driven low" is NOT something you'd expect to get from a datasheet description. IIC is essentially timing independent as long as setup and hold times are met. ie not like eg asynch or synchronous serial comms which are clock rate dependant – Russell McMahon Apr 11 '12 at 11:03
• On an open-drain multidrop bus there's no "driven high". The open drain can only drive low. The opposite is "bus release". – Federico Russo Apr 11 '12 at 11:14

The specification says that the ACK consists of a low level after the 8th clock pulse, as shown by this diagram:

The bus master will generate a 9th clock pulse to read the level. The specification doesn't talk about pulsing ACK, and the master will not take notice of it either. Follow the spec and take care of data setup and hold times (250ns and 5$\mu$s resp. for standard mode) to be sure that the level is properly detected.

What you see as a spike in the ACK is not part of the ACK, but a bus release between the ACK and a low-level first databit of the next word. The bus release comes after SCL goes low again, both in your and my diagram. According to the diagram above this release is required; note that the low level of the SDA after ACK is interrupted, indicating that SDA must go high.

Note: the bus release isn't shown on the timing diagram, figure 38, nor is timing given in the AC characteristics. I couldn't find any reference to it in the spec's text. There's also no SCL activity during this SDA high. This suggests that the bus release isn't really required. In that case the diagram contains an error, apparently copied by others, like in the TMP175 datasheet.

edit
Madmanguruman comments that the ACK comes from the slave, while the next databit comes from the master. This will often be the case, and he has a point. The next databit will also come from the slave, however, if it's the reply from the slave to a read command. Then it would make perfectly sense that the slave doesn't release the bus.

• I see, thanks. I'm still puzzled by this spike I see in the datasheet timing diagram. What could it be? – Randomblue Apr 11 '12 at 10:05
• @Randomblue, could you post a screenshot of the diagram? – avakar Apr 11 '12 at 10:15
• @Madmanguruman - Correct, but the question is: do you have to release the bus between ACK (low) and the first bit of the next byte if this is zero (also low). In that case you might as well keep the level low. Graph says you have to release the bus in between both low levels, but this isn't confirmed in the rest of the spec. – stevenvh Apr 11 '12 at 14:35
• @stevenvh The ACK is the receiver holding SDA low. The receiver has to release the bus to allow the transmitter to communicate - it doesn't have advance knowledge of the next bit! – Adam Lawrence Apr 11 '12 at 15:03
• @Madmanguruman - Good point. The next byte may be a reply from the receiver, however, when the master executes a read command. – stevenvh Apr 11 '12 at 15:06

I was trying to get a I2C DAC working the other day and I had this very same question. The bus master / host sends a byte to a device and once the device successfully received it, it pulls the data line (SDA) low to indicate to the bus master the byte was received. The DAC's datasheet mentioned a device connectivity test by looking for the ACK from the device. Having access only to a analog oscilloscope I quickly figured out that the DAC was quite likely not sending ACK's, because the frame on the serial bus was only long enough for a single byte whereas I'd expect three consecutive bytes. On top of that I wasn't able to find a convincing ACK in the signal (a low bit). I figured that the bus master / host might be intelligent enough not to send the second byte if it didn't receive an ACK from the receiver, the DAC. That would explain why I saw too short messages passing the I2C bus. With the DAC being a fairly simple device, the only option I could think of was using a wrong device address. So I started to try addressing the DAC with different addresses and pretty quickly I spotted a frame on the serial bus that was much longer than the other ones.

Now to answer your question: Once I was able to succesfully address the DAC I noticed an interesting effect. With my scope probe attached near to the DAC, the ACK pulse was clearly visible on the analog scope. Where all bits sent from the host had a certain minimum voltage level, the ACK pulses were pulled much better to 0V. So for example, 0-bits sent from the host would measure about 0.2V, the ACK's would measure 0.1V. The values in this example are just made up to illustrate my point. This made the ACK pulses clearly stand out from the rest of the data stream.

Any I2C transaction in progress will be terminated if SDA changes while SCK is high. Any I2C device which will want to assert or release SDA must either do so at a time when it can be certain that SCK isn't going to rise. There are two ways a device can be certain SCK isn't going to rise: (1) it can be asserting SCK itself, or (2) if it sees a falling edge on SCK, it can know that SCK will remain low for a certain minimum amount of time (depending upon bus speed). Because most I2C slave devices never assert SCK themselves, the only time they can safely change what they're outputting on SDA is immediately following a falling edge of SCK.

An I2C master, however, is free to change the state on SDA any time it is asserting SCK. To read the state of a remote device's ACK bit, the master must release SDA before the rising clock edge following the ack, and must leave it released until after the next falling edge of SCK. Even if the first transmitted bit after the "ack" should be a "0", the master should delay between the assertion of SCK and the assertion of SDA. The fact that slaves react immediately to a falling edge on SCK, while masters must add a delay between driving SCK and SDA, means that on a "hand-off" of control from the slave to the master, there will often be a brief moment when neither device will consider it appropriate to assert SDA (technically, the required minimum delay between the master's assertion of SCK and its assertion of SDA is smaller than the required maximum between the master's assertion of SCK and the slave's release of SDA, but most masters delay longer than that).

Incidentally, if no slaves use clock stretching, one can easily tell on a scope plot which SDA changes are caused by the master and which are caused by the slave. If SDA changes at the same time as SCK switches from high to low, the change is caused by the slave. If SDA changes at any other time, the change is caused by the master.