Prev: FPGA Boards
Next: ISE7.1 PAR Warinng: excessive skew because 1 NON-CLK pins...
From: praveen.kantharajapura on 10 Jun 2005 00:31
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

From: Kryten on 10 Jun 2005 08:49
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.

> if I want Clock stretching the slave also will
> be driving the SCL low when required to keep the master on hold.

Correct.

> In this case SCL will be an INOUT for my module.

Correct.

> My question is how to go about this implementation(tristate buffers on
> SCL!!!).
> What 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.

Correct.

> please comment on this implementation.

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.




From: John_H on 10 Jun 2005 09:23
Kryten wrote:
> 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.

<snip>

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.
From: Gabor on 10 Jun 2005 11:33


John_H wrote:
> Kryten wrote:
> > 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.
>
> <snip>
>
> 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.

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.

From: Kryten on 10 Jun 2005 18:03

"Gabor" <gabor(a)alacron.com> wrote in message
news:1118417613.834535.32380(a)g43g2000cwa.googlegroups.com...

>> A master has to support clock stretching to be I2C compliant.

Yes.

>> 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.

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.


> 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.

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

But the master always have to cope with clock stretching.

> 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.

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.

> 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 synchronize the start of the stretch pulse to the
> falling edge of SCL.

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.



 | 
Pages: 1
Prev: FPGA Boards
Next: ISE7.1 PAR Warinng: excessive skew because 1 NON-CLK pins...