This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TPS546D24A: What scenarios need clock stretching?

Part Number: TPS546D24A

Hi Sir,

I want to know what kind of scenarios will TPS546D24A pull clock down to indicate clock stretching busy. Why will the device need this? 

If the device need time to process the command, can i just extend the time interval between commands and commands to make sure the clock is not stretched? 

-A

  •  

    I want to know what kind of scenarios will TPS546D24A pull clock down to indicate clock stretching busy.

    The section of the datasheet that you included in your post is very explicit about when the TPS546x24A family of devices may stretch the clock.

    Any of the listed bit-intervals may be clock-stretched on any command.

    Why will the device need this? 

    The TPS546x24A uses shared logic for many internal functions, including validating supported commands, validating data, converting internally stored data into PMBus linear formats, converting PMBus formats into internally stored data and buffering command data longer than 4-bytes.  When PMBus transaction are occurring while this shared logic is busy with other tasks and not available for processing PMBus transaction, the CLK pin will be held low until the shared logic is available.

    If the device need time to process the command, can i just extend the time interval between commands and commands to make sure the clock is not stretched? 

    No, clock strentching occurs during a command, most often during the acknowledgement of the transferred byte, when the TPS546x24A needs to determine if the byte will be ACKed or NACKed, or when preparing read data to be sent after receiving a repeated start and its address with a read-byte.

    If the internal logic is still processing a previous command when a new command is received, the clock will be stretched between bit 0 of the command code and the ACK of the command code byte, but increasing the time between commands will not necessarily eliminate clock-stretching at this time as the shared logic for determining the command-code ACK/NACK response may be busy with other functions even if time is provided since the previous command was processed.