I2C speed

[Piotr Wyderski]

Hi,

I need to bit-bang a fast mode I2C stream and started reading the I2C
specs from Philips carefully. Table 11 says the minimal SCL period
(tLOW) is 1300ns, while tHIGH is 600ns. That implies f_SCL_MAX=526kHz.
OTOH, the very first row of Table 11 says f_SCL_MAX=400kHz. While it
would be easy to scale tLOW and tHIGH to make both meet their required
minima AND make tLOW+tHIGH >= 2.5us, what's the point of defining the
timing in such a confusing way? Per my understanding, a conforming slave
must be able to work with the minimal tLOW and tHIGH anyway, i.e. at
526, not 400kHz.

Best regards, Piotr

[Don Y]

You're reading more into it than is there.

The frequency will not exceed 400KHz.
t(hi) will never be less than 600ns.
t(lo) will never be less than 1300ns.

Meet each of these criteria and you are golden.

[olaf]

Piotr Wyderski <bom...@protonmail.com> wrote:

>must be able to work with the minimal tLOW and tHIGH anyway, i.e. at
>526, not 400kHz.

400khz is the standard value everybody knows. For example I play in these
days a little with NCA9555 and the datasheet said 400khz. But I know
from experiment that 2000khz works well.
We can not complain that someone sell us something better we paid for.

Olaf

[Ricky]

I forget who it was that said we should make things as simple as possible, but not simpler.

The specs, tLOW and tHIGH do not create a spec for the minimum period. Your idea that you should be able to cycle the clock at 526 kHz is faulty. While that might satisfy both tLOW and tHIGH, there are other factors inside a given chip or interface that sets the minimum period to 2,500 ns. There is nothing in this spec that says it's ok to use the minimum value of both tLOW and tHIGH, if the sum is less than 2,500 ns.

I forget the part number, but there's a well known chip for interfacing a basic 20x2 (and other sizes) LCD display to an MCU. It has a number of specifications that allow the bus cycle to operate at up to some MHz value. But... there are some instructions that run slower, so this max bus rate can not be used with *those* instructions. I believe there is a FSM inside (perhaps even a crude MCU) that interprets the instructions sent to the chip, such as "clear all". I think it copies null data to all memory locations, sequentially.

--

Rick C.

- Get 1,000 miles of free Supercharging
- Tesla referral code - https://ts.la/richard11209

[Piotr Wyderski]

Don Y wrote:

> The frequency will not exceed 400KHz.
> t(hi) will never be less than 600ns.
> t(lo) will never be less than 1300ns.
>
> Meet each of these criteria and you are golden.

Sure, and that's what I'm going to do. I'm just curious where the
missing 126kHz are. 526/400 is quite a substantial transmission speedup,
so IMHO the question is worth asking. A conforming slave needs to meet
the t-s anyway, so why capping it by the f-s?

Best regards, Piotr

[Ricky]

And we can not complain if the first few units we test work much faster, but our production runs fail to work in the field because we are running it outside the spec. PVT, Process, Voltage and Temperature. We can control and test over V and T, but P is beyond our control and therefore ability to test.

--

Rick C.

+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209

[Don Y]

On 7/30/2023 1:05 AM, Piotr Wyderski wrote:
> Don Y wrote:
>
>> The frequency will not exceed 400KHz.
>> t(hi) will never be less than 600ns.
>> t(lo) will never be less than 1300ns.
>>
>> Meet each of these criteria and you are golden.
>
> Sure, and that's what I'm going to do. I'm just curious where the missing
> 126kHz are.

They don't exist.

> 526/400 is quite a substantial transmission speedup, so IMHO the
> question is worth asking. A conforming slave needs to meet the t-s anyway, so
> why capping it by the f-s?

They are independent criteria. t(lo) + t(hi) != t(cyc)

If a particular cycle (out of an endless stream of cycles)
begins with the signal being LOW for t(lo), then you can
infer that it will be HIGH for 2500-t(lo) -- assuming
instantaneous transitions. Likewise, if it is HIGH for
t(hi), you can infer that it will be LOW for 2500-t(hi).

These are constraints you can apply to *it* if you are
the "consumer" of those signals.

[Piotr Wyderski]

Ricky wrote:

> The specs, tLOW and tHIGH do not create a spec for the minimum period. Your idea that you should be able to cycle the clock at 526 kHz is faulty. While that might satisfy both tLOW and tHIGH, there are other factors inside a given chip or interface that sets the minimum period to 2,500 ns. There is nothing in this spec that says it's ok to use the minimum value of both tLOW and tHIGH, if the sum is less than 2,500 ns.

I am not arguing with that and had already chosen to follow the way
suggested by DonY before starting this thread. I'm asking what technical
reasons imply specifying it the way it's been specified. What needs the
additional delay?

Best regards, Piotr

[Piotr Wyderski]

olaf wrote:

> We can not complain that someone sell us something better we paid for.

It's not about exceeding the specs, the (particular instances of) parts
work at 526kHz just fine. I just don't understand where the f-related
delay goes, because it leaves a hefty headroom relatively to what the
t-s say.

I plan to meet all the criteria, that's not the point.

Best regards, Piotr

[Don Y]

Look at it the other way. Assume f(max) is 400KHz.
Would you expect that to dictate that t(hi) is 1250
and t(lo) is also 1250 -- so that t(cyc) would be 2500?

Or, if t(lo) is 1300, then t(hi) *must* be 1200?

I.e., so there is no way *possible* to create a device
that would operate at f(max) > 400KHz?

What the spec does is lay out what you can reliably expect
from a conforming set of signals. So, if you can tolerate
those extremes, you'll be golden.

Think of a pair of FF's one (Q) feeding the other (D).
There's a max propagation delay from clock to Q output
on the first FF. There's a min setup time for the D
input to the clock on the second FF. Yet, the maximum
clock frequency need not be related to t(pd)+t(sup).

Furthermore, there's likely a t(hold) on the D input...
some time AFTER the clock edge that the input must remain
stable for proper operation of the FF. The t(pd) from the
first FF doesn't GUARANTEE that the output WON'T change
quicker than advertised. I.e., it could change in 0ns.
If so (assuming no propagation delays), any t(hold) > 0
will cause the second FF's specifications NOT to be met.

You can only count on the min/max numbers that are
published. Often, t(min) is not present and, increasingly,
t(max) is replaced by t(typ)!

The manufacturer (and/or specification creator) is
giving leeway to the silicon vendor in defining the
criteria that he *must* meet (over voltage, temperature
and process variations). And, at the same time,
telling you what his "contract" with you will be.
He can exceed ("better than") those numbers but never
*worse*. So, if you design for those limits, you are
"guaranteed" to have a successful implementation.

[Don Y]

Have a quick read of:

<https://idc-online.com/technical_references/pdfs/electrical_engineering/Process_Voltage_Temperature_PVT_Variations_and_Static_Timing_Analysis.pdf>

Or, dig up an (old) copy of Mead & Conway for a better understanding
of the physics/material science issues involved.

(I have no idea what the modern equivalent is as I've been out of
that business since the 80's)

[Piotr Wyderski]

Don Y wrote:

Than you, I think I can see what you mean. But look what I2C *is*:

1. There's the protocol control part (the S/P/repeated S) that is not
periodic, so it is defined purely in terms of t-s. That part is crystal
clear.

2. The content transfer indeed depends on a periodic SCL signal, but
then a conforming implementation must discriminate between SDA_ACTVE and
SDA_IDLE reliably, and the same about the clock signal segments. This
reliability is defined in terms of tLOW and tHIGH. Anything that
recognizes idle for >=600ns and active for >=1300ns is conforming.
That's clear, too.

3. Anything that can work with 600ns pulses should have no issues with
1900ns pulses either. Because physics.

4. So since the circuit must have decoded the 600ns pulses reliably
*and* these are already available on the silicon chip *and* the receiver
is a synchronous shift register clocked by the SCL in that transfer
phase, what makes this shift register incapable of shifting data at
526kHz? The specs says 1/(600ns+1300ns+x)<=400kHz. What's the x? Even
the most simplistic implementations of the shift register would have the
x==0 (i.e. the setup and hold times would be hidden under the timing of
the other protocol segments that follow), so who ordered that x >> 0?
What's the rationale behind the f cap?

Best regards, Piotr

[Don Y]

On 7/30/2023 2:29 AM, Piotr Wyderski wrote:
> Don Y wrote:
>
> Than you, I think I can see what you mean. But look what I2C *is*:
>
> 1. There's the protocol control part (the S/P/repeated S) that is not periodic,
> so it is defined purely in terms of t-s. That part is crystal clear.
>
> 2. The content transfer indeed depends on a periodic SCL signal, but then a
> conforming implementation must discriminate between SDA_ACTVE and SDA_IDLE
> reliably, and the same about the clock signal segments. This reliability is
> defined in terms of tLOW and tHIGH. Anything that recognizes idle for >=600ns
> and active for >=1300ns is conforming.
> That's clear, too.

RECOGNIZE is not the same as GENERATE The specification determines what
must be "extractable" from the signals. Why not set these limits to
outrageously small values to maximize performance? (Ans: because then
they wouldn't be reliably detected -- as different from noise spikes)

Specifying modest minimum values allows for the possibility of synchronous
detectors (without requiring outrageously high sampling rates)

> 3. Anything that can work with 600ns pulses should have no issues with 1900ns
> pulses either. Because physics.
>
> 4. So since the circuit must have decoded the 600ns pulses reliably *and* these
> are already available on the silicon chip *and* the receiver is a synchronous
> shift register clocked by the SCL in that transfer phase, what makes this shift
> register incapable of shifting data at 526kHz? The specs says

It can likely shift at much higher rates. The point is, it is not REQUIRED
to operate at anything beyond 400KHz.

If you encounter some implementation that is entirely synchronous, you
may discover that the data can't be *seen* at the rate that it is
occurring on the wire if you exceed the limits of the specification?
The specification is a contract between the various parties interacting
with the bus (otherwise, just implement your own standard and run it
as fast as you'd like!)

UARTs typ oversample at 16x the bit rate. So, why shouldn't the top bit rate
ALWAYS be 16x whatever the *current* bitrate happens to be? (Ans: because
there are practical limits on what you would WANT the maximum bitrate to be...
based on how you APPLY that technology)

> 1/(600ns+1300ns+x)<=400kHz. What's the x? Even the most simplistic
> implementations of the shift register would have the x==0 (i.e. the setup and
> hold times would be hidden under the timing of the other protocol segments that
> follow), so who ordered that x >> 0?
> What's the rationale behind the f cap?

It's a SPECIFICATION, not an EXPLANATION.

As elsewhere, would you *require* t(lowmin) + t(himin) to equal t(cycmin)
i.e., 1/f(max)? Obviously, you can EXPLAIN that the *observed* t(lo)
plus the observed t(hi) WILL equal the observed t(cyc). But, that doesn't
translate to specifying the t(lowmin) + t(himin) should equal t(cycmin).

[Lasse Langwadt Christensen]

see it as limit on duty cycle not frequency

[Don Y]

No, because -- as freq changes -- the duty cycle limits change.

It's a limit on minimum resolvable "bus event" that implementations
must be able to reliably detect, regardless of frequency.

(Let those values fall and see how it affects the operation
of a synchronous detector feeding a synchronous machine)

[Lasse Langwadt Christensen]

søndag den 30. juli 2023 kl. 17.16.46 UTC+2 skrev Don Y:
> On 7/30/2023 8:03 AM, Lasse Langwadt Christensen wrote:
> > søndag den 30. juli 2023 kl. 09.15.38 UTC+2 skrev Piotr Wyderski:
> >> Hi,
> >>
> >> I need to bit-bang a fast mode I2C stream and started reading the I2C
> >> specs from Philips carefully. Table 11 says the minimal SCL period
> >> (tLOW) is 1300ns, while tHIGH is 600ns. That implies f_SCL_MAX=526kHz.
> >> OTOH, the very first row of Table 11 says f_SCL_MAX=400kHz. While it
> >> would be easy to scale tLOW and tHIGH to make both meet their required
> >> minima AND make tLOW+tHIGH >= 2.5us, what's the point of defining the
> >> timing in such a confusing way? Per my understanding, a conforming slave
> >> must be able to work with the minimal tLOW and tHIGH anyway, i.e. at
> >> 526, not 400kHz.
> >
> > see it as limit on duty cycle not frequency
> No, because -- as freq changes -- the duty cycle limits change.
>
> It's a limit on minimum resolvable "bus event" that implementations
> must be able to reliably detect, regardless of frequency.

so at a frequency there is limit on duty cycle, but I'm sure there is a way to write
pages of nitpick about it ...

[Don Y]

At *any* frequency (because the frequency isn't set in stone), there is
a limit on pulse width.

Would you want to have to change the operating frequency of the I2C
controller because some other device on the bus decided to operate at
a different *bus* frequency? Or, would you just want to ensure you
could detect the minimum bus event regardless of bus frequency?

[Ricky]

You trimmed my post where I explain why the LCD controller was like this. What part of that did you not understand?

How do you expect anyone else to know the details of a spec they didn't write?

One point I forgot to mention is that this is an open collector/drain bus. There needs to be time allowed for settling of the bus, i.e. transition time. Not that this will account for the remaining time. Do they specify the tLOW and tHIGH to include the transition time, or are these numbers exclusive of the transition times?

--

Rick C.

-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209

[Don]

Table 11 in Rev. 7.0 — 1 October 2021 of the specs, available at
<https://www.nxp.com/docs/en/user-guide/UM10204.pdf>, contains a column
called "Fast-mode Plus" and shows f_SCL_MAX=1000kHz.

Danke,

--
Don, KB7RPU, https://www.qsl.net/kb7rpu
There was a young lady named Bright Whose speed was far faster than light;
She set out one day In a relative way And returned on the previous night.

[Don]

Don <g...@crcomp.net> wrote:
> Piotr Wyderski wrote:
>
>> Hi,
>>
>> I need to bit-bang a fast mode I2C stream and started reading the I2C
>> specs from Philips carefully. Table 11 says the minimal SCL period
>> (tLOW) is 1300ns, while tHIGH is 600ns. That implies f_SCL_MAX=526kHz.
>> OTOH, the very first row of Table 11 says f_SCL_MAX=400kHz. While it
>> would be easy to scale tLOW and tHIGH to make both meet their required
>> minima AND make tLOW+tHIGH >= 2.5us, what's the point of defining the
>> timing in such a confusing way? Per my understanding, a conforming slave
>> must be able to work with the minimal tLOW and tHIGH anyway, i.e. at
>> 526, not 400kHz.
>
> Table 11 in Rev. 7.0 — 1 October 2021 of the specs, available at
> <https://www.nxp.com/docs/en/user-guide/UM10204.pdf>, contains a column
> called "Fast-mode Plus" and shows f_SCL_MAX=1000kHz.

Never mind. Your desire to use fast mode is clearly stated above.
"Misery loves company." It also confuses me when things won't add up. My
instinct is to blame it on sloppy, half-baked, work product.

[Piotr Wyderski]

Don wrote:

> Never mind. Your desire to use fast mode is clearly stated above.

The slowest slave on the bus is specified to support only fast mode, so
I have no choice but to comply.

Best regards, Piotr

[Jan Panteltje]

On a sunny day (Sun, 30 Jul 2023 20:19:27 +0200) it happened Piotr Wyderski
<bom...@protonmail.com> wrote in <ua69jf$3m59o$1...@portraits.wsisiz.edu.pl>:

How does that work?
The advantage of i2c is that you can interrupt it.
this allows it to be used in a multi-tasking system where it can be interrupted all the time.
No minimal speed specified.

[Piotr Wyderski]

Jan Panteltje wrote:

> How does that work?

It's a regular single master I2C bus driven from a PicoBlaze. The
slowest device is fast mode, so all of them need to be fast mode.

> The advantage of i2c is that you can interrupt it.

I hate I2C, too many things can go wrong. But there are no SPI variants
of the chips I need, so I have no choice.

> No minimal speed specified.

Yup, I2C is all about the SCL/SDA edges.

Best regards, Piotr

[Jan Panteltje]

On a sunny day (Mon, 31 Jul 2023 07:58:51 +0200) it happened Piotr Wyderski
<bom...@protonmail.com> wrote in <ua7iir$3mtta$1...@portraits.wsisiz.edu.pl>:

>Jan Panteltje wrote:
>
>> How does that work?
>
>It's a regular single master I2C bus driven from a PicoBlaze. The
>slowest device is fast mode, so all of them need to be fast mode.

Still wonder, you can drive any device slower than fastmode, never seen one specified that MUST use fast mode.
Or are you sending / receiving data at high speed that needs it?

>> The advantage of i2c is that you can interrupt it.
>
>I hate I2C, too many things can go wrong. But there are no SPI variants
>of the chips I need, so I have no choice.

I like it, even did an external i2c network in an office building showing data on displays...
Used differential drive and interface chips...
Hundreds of meters...

Not sure if I used SDA pulldown to confirm....
Early eighties.

>> No minimal speed specified.
>
>Yup, I2C is all about the SCL/SDA edges.

Indeed.

[Piotr Wyderski]

Jan Panteltje wrote:

> Still wonder, you can drive any device slower than fastmode, never seen one specified that MUST use fast mode.
> Or are you sending / receiving data at high speed that needs it?

Oh, sure, there probably is none. I want to complete the transfers as
fast as possible. "Fast mode" is slow enough not to consider going down
to 100kHz. It's not about the bus frequency itself, but about the query
delay it introduces.

> I like it, even did an external i2c network in an office building showing data on displays...
> Used differential drive and interface chips...
> Hundreds of meters...

I have 125MHz LVDS for interfacing the external world. This one is an
entirely on-board issue.

Best regards, Piotr

[Lasse Langwadt Christensen]

except when it is actually SMBus like many devices on a motherboard, it has a timeout
to resolve the lockups I2C is prone to if you look at it the wrong way

[John Walliker]

An essential component of an i2c controller is a power switch for all the slaves.
(Yes, I do know about clocking errors out, but it doesn't work EVERY time.)

I have regularly used i2c over 10m cables at 100kHz and even got it through EMC immunity
testing for CE marking over unshielded cables, but it does help to have a linear bus structure
and to provide some RC damping at one end at least.
John