# 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
@stevenvh Good to know! Thanks. –  AndrejaKo Apr 11 '12 at 10:16
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

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
@Randomblue - added to my answer. –  stevenvh Apr 11 '12 at 10:19
@avakar: Done now. –  Randomblue Apr 11 '12 at 10:56
@Randomblue It's not a spike. The bus is released after the ACK and goes high. SCL is low here, remember, so SDA is allowed to change. The first bit being transmitted after the ACK is 0, so SDA gets pulled down. If the first bit being transmitted after the ACK is 1, it would simply stay high. –  Madmanguruman Apr 11 '12 at 14:29

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.

-