I2C clock stretching(XILINX reference design)

Hi all,

I am implementing a I2C slave. I am refering XAPP333 for my deisgn. But one of the "limitation" of that reference design from XILINX is that it does not support "clock stretching".

Suppose we do not need clock stretching "SCL" will be taken as INPUT to my I2C slave block.But if i want Clock stretching the slave also will be driving the SCL low when required to keep the master on hold.In this case SCL will be an INOUT for my module.

My question is how to go about this implementation(tristate buffers on SCL!!!). Waht i am planning to do is, i will pull the SCL line low whenever i want to stop the clock transition on SCL from master else i will drive a "Z" on SCL.

please comment on this implementation.

Regards, Praveen

Reply to
praveen.kantharajapura
Loading thread data ...

Hi Praveen (again).

If the Xilinx app not does not support clock stretching, it has not met the I2C spec and has no right to claim it is I2C. Clock stretching is an essential part of I2C, it was put in there to allow proper operation with slower I2C slaves.

I2C slaves _and_ masters have to wait for SCL to go high after they release it.

Correct.

Correct.

Correct.

This is all in the I2C spec.

I'm staggered at how many people have difficulty understanding it. Arizona Microchip application notes are/were really bad implementations.

I'm surprised if Xilinx have written similar half-assed examples.

Reply to
Kryten

A master has to support clock stretching to be I2C compliant. Clock stretching is used by slaves that need time to process data. If a slave doesn't need the extra time, it doesn't need to stretch the clock and can maintain I2C compliance without clock stretching.

Reply to
John_H

Good point. A lot of IC's with I2C slaves show the SCL pin as an input-only. The Xilinx app assumes you're getting data from inside the FPGA which should never require stretching even at the fastest bit rates.

A clock stretcher usually only asserts SCL during the ACK cycle of the access requiring more time. This is not a requirement, but it keeps a slave from stretching SCL cycles that are not intended for that slave, as might happen if the address is still being sent.

Also make sure that the decision to stretch or not stretch does not come more than Tlow (min) after the falling edge of SCL or you may have a race condition allowing the SCL to "double pulse". It's probably best to syncronize the start of the stretch pulse to the falling edge of SCL.

Reply to
Gabor

Yes.

True.

The key point is that clock stretching allows any master to work with any slave.

Omitting it inserts an Achilles heel in the design.

It is really irritating when people publish interfaces with such flaws. Even more so when the authors acknowledge the flaw and then waffle their excuses for not doing it the way it ought to work.

If the slave runs fast enough it never needs to stretch the clock.

But the master always have to cope with clock stretching.

IIRC any slave should be able to stretch the clock at any bit. For example, and extremely slow slave might need to slow do the address bit rate in order to read all the bits. It doesn't matter if the address is for it or not, it still needs its own time to read it.

I thought a good way to clock stretch is to have a gated 3s buffer with the in and out both wired to SCL. Like a 74LS125 (IIRC). With the enable negated, it acts as if it were not there. With the enable asserted, it is 'armed': when the SCL line goes low, the gate locks it low (for the slave to take its own sweet time to note it). The slave then negates the enable to allow SCL to float.

Reply to
Kryten

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.