S
1
2
PMBUS_CLK
PMBUS_DATA
t
START
UNIT_BUSY
DATA_REQUEST(1)
Slave Address
A
7
8
R/W
Write to ACK
(Stretch)
t
DREQ1
t
ACKWRITE
t
X
Avoiding Clock Stretching
367
SNIU028A – February 2016 – Revised April 2016
Copyright © 2016, Texas Instruments Incorporated
PMBus Interface/I2C Interface
10.4 Avoiding Clock Stretching
For many applications, clock stretching is acceptable, but there may be requirements for minimal or no
clock stretching. The UCD3138 family PMBus/I2C architecture permits this for some cases
For example, write messages up to 3 bytes and command can be handled in one operation using the 4
byte buffer and automated ACK. This gives an entire byte time for the firmware to respond, assuming that
the master sends another message to the slave immediately after the first message. Even at 1 MHz, this
is about 8 µsec, which should be time enough for a quick interrupt function to collect the data.
Read is more problematic. Using conventional methods, it should be possible to handle read messages, at
least at 100 KHz. Here is the relevant timing diagram, assuming automatic slave address ACK is used:
Figure 10-15. Clock Stretch Timing for Read
t
X
shows the timing caused by the combination of the firmware and the interface delays.
t
X
= t
DREQ1
+ firmware delay + t
ACKWRITE
To avoid clock stretching, t
X
needs to be smaller than the clock low time for the PMBus/I2C clock speed.
Since t
DREQ1
+ t
ACKWRITE
= 1.076 µsec maximum, it’s possible to just subtract this number from the minimum
clock low time for the data rate.
At 100 KHz, clock low minimum is 4.7 µsec, giving about 3.7 µsec for firmware, which should be attainable
with an optimized interrupt.
Obviously the minimum clock low time of 1.3 µsec at 400 KHz gives less that .3 µsec for the firmware,
which isn’t enough.
10.4.1 Using Early TXBUF Write to Avoid Clock Stretch
It hasn’t been tested exhaustively for robustness, but it may be possible to use early writes to TXBUF to
avoid a clock stretch. The standard PMBus firmware actually writes to TXBUFF early on a read. It writes
as soon as the interface receives the repeated start signal. This gives an entire byte delay for the receipt
of the slave address with the read bit set for the firmware to respond.
This approach can also be used in an I2C case where the command is first written with a write message,
and then the read is done with a simple read address. It is possible to write to the TXBUF register when
the command is written, then the read will get the values that were written.
This method doesn’t help, though, with messages that use more than one RXBUF or TXBUF full. In those
cases, it is necessary to detect the data request or data ready, and deal with the RXBUF or TXBUF in a
half clock cycle. So longer messages will definitely require clock stretching at frequencies over 100 KHz.