• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 3504 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

TMDS181 DDC Snooping

Igor Uspensky
Intellectual 670 points
Other Parts Discussed in Thread: TMDS181, TMDS141

Hi

According to TMDS181 data sheet (section 8.4.3 DDC Training for HDMI2.0a Data Rate Monitor)

"As part of discovery, the source reads the sink’s E-EDID information to understand the capabilities of the sink. Part of this read is HDMI Forum Vendor Specific Data Block (HF-VSDB) MAX_TMDS_Character_Rate byte to determine the data rate supported. Depending upon the value, the source writes to slave address 0xA8 offset 0x20 bit1, TMDS_CLOCK_RATIO_STATUS. The TMDS181 snoops this write to determine the TMDS clock ratio and thus sets its own TMDS_CLOCK_RATIO_STATUS bit accordingly."

Next, it is stated in Table 6. (MISC CONTROL Register Fields Descriptions), the string describing the bit 1 of the register 0Bh:

"TMDS_CLOCK_RATIO_STATUS. This field is updated from snoop of DDC write to RWU slave address 0xA8 offset 0x20 bit 1 that occurred on the SDA_SRC/SCL_SRC interface. When bit 1 of address 0xA8 offset 0x20 in the SCDC register set is written to a 1’b1, then this field will be set to a 1’b1. When bit 1 of address 0xA8 offset 0x20 is written to a 1’b0, then this field will be set to a 1’b0. This field is reset to default value whenever HPD_SNK is de-asserted for greater than 2 ms."

I have a couple of questions.

1. Please confirm the part monitors writes to the slave address 0xA8 and not to the address 0x54.

2. According to the description text, the part snoops on its SDA_SRC/SCL_SRC pins (not on the SDA_SNK/SCL_SNK ones). Let's consider a hypothesis scenario where the source writes to the sink's TMDS_Config register responding to SCDC Read Request from the sink (that is when I2C Start condition was generated by the sink). If the part is able to detect the bit1 state changing in such case?

Actually these questions are applicable also to SN65DP169 part as it looks behaving similar concerning that matter.

---

regards,

    Igor

  • 0
    TI__Guru 60870 points

    Hi Igor,

    1. Yes, the DDC address that is monitored for TMDS Bit Clock Ratio is A8h.

    2. It looks like the datasheet needs to be clarified here.  If the TMDS181 is being used in snoop mode where only the SCL_SNK and SDA_SNK are connected to the DDC lines, then the snoop actually occurs on the SCL_SNK / SDA_SNK lines.  If the TMDS181 is being used to retime / level shift the SCL_SRC / SDA_SRC to SCL_SNK / SDA_SNK, it will snoop the access to the register with TMDS Bit Clock Ratio as the write goes from the source to the sink.

    Regards,

    JMMN

  • 0 in reply to JMMN
    Intellectual 670 points
    Hi JMMN,

    Thanks for the clarification.

    By the way it seems the "active DDC block" in TMDS181 is of much more internal complexity in comparison for example with that for TMDS141. I guess it's derived/reused from SNx5DP159 where is acts as DP Aux<->I2C bridge (hence clock stretching). The pre-production data sheet for TMDS181 does not provide enough information for how exactly that clock stretching works so no wonder the others already reported about the related problem.

    Indeed it seems currently the safe approach would be don't use the active ddc block at all opting to connect only SCL_SNK and SDA_SNK to the DDC lines (as shown on the figures 35 and 36 in the DS) and use an external part for level shifting, if necessary.

    Again the text does say nothing but one may conclude that in such configuration the active DDC block is actually disabled (by grounding SDA/SCL_SRC) so there will be no unwanted effects. Could you clarify if the DDC_DR_SEL setting (bit 2 of register 0Bh) still makes a difference in that case?

    ---
    regards,
    Igor
  • 0 in reply to Igor Uspensky
    TI__Guru 60870 points

    Hi Igor,

    First, I need to correct my earlier statement: the register with the TMDS Bit Clock Ratio is defined as A8h per the specification, but using the 7-bit I2C address format, it would be 54h. 

    The TMDS181 does have a more complex DDC circuit than previous devices.  The clock stretching feature is defined in the publicly available I2C specification so we didn't re-document it in the datasheet, but the short version is that the TMDS181 can hold SCL low on the source side while waiting for a response from the SNK.  During interoperability testing we found that some sources did not support clock stretching and so we have suggested that customers can implement DDC snoop mode, where the DDC lines are only connected to the TMDS181 SCL_SNK / SDA_SNK and the SCL_SRC / SDA_SRC lines are grounded to prevent noise from being interpreted as traffic and driven to the sink.  The DDC_DR_SEL should not matter for that case.

    Regards,

    JMMN

  • 0 in reply to JMMN
    Intellectual 670 points

    Hi JMMN,

    Absolutely! You've got my point. There are two notations for I2C device addresses and for the 7-bit format it may not be always evident of which format the number is.

    As for the clock stretching, thank you for reminding the definition. I'd like to add about the implications. Besides of making the design more complex, the clock stretching can introduce an interop problems (as you'd already mentioned). Moreover it degrades the throughput. Because of that we rarely can see a design that is doing clock stretching without a sound reason for that. So what i'm trying to figure out for myself is why TMDS181 uses clock stretching. My speculations:

    1. For the DDC snooping purposes. The part have to eavesdrop on I2C traffic to automatically update the TMDS clock ratio control bit. Because of its internal limitations, the snooping circuitry is not always able to decode the bus transactions in real time so it uses clock stretching to slow the traffic down when necessary. But as I understand there is no clock stretching in the application designs where the SCL/SDA_SRC pins are grounded. So this is unlikely the case.
    2. For the signal conditioning purposes. When the SCL/SDA_SRC pins are in use, the active DDC block enforces I2C compliance by driving the SCL line low for the time interval, which is equal to min. low pulse duration defined in the I2C spec. Some kind of bonus feature. But the numbers does not prove that speculation. According to the section 6.12 (DDC and I2C Switching Characteristics) in the DS, the tLOW parameter (pulse duration, SCL low) is required to be at least 1.3 us (assuming the numbers in the table are also related to the input signals, i.e., to the source side DDC pins). That value is equal to that defined in the Philips I2C-bus specification, V2.1 for the fast mode (400 kHz clock). Consequently, there is no need for clock stretching. In the fast mode anyway.

    So the very reason for clock stretching in TMDS181 remains mysterious.

    ---

    regards,

        Igor

  • 0 in reply to Igor Uspensky
    TI__Guru 60870 points
    Hi Igor,

    The TMDS181 implements clock stretching since it acts as a I2C repeater, not just a level shifter - an I2C slave on the source facing side and an I2C master on the sink facing side. There are times when the TMDS181 slave function cannot respond to the source until it receives a response from the downstream sink and this is the reason for the clock stretching ability.

    Regards,
    JMMN
  • 0 in reply to JMMN
    Intellectual 670 points

    Hi JMMN,

    Thanks for the clarification. So my understanding is that each time eight data bits from the master device has received, the Active DDC Block of TMDS181 ties the SCL line low and starts waiting for acknowledge bit from the slave. Is there a provision for negative acknowledge (timeout or something)? NACK is a valid response and source devices shall handle it as specified in E-DDC standard (section 3.1.2 Enhanced DDC Host System Connected to a Legacy DDC Display). How to implement this in a source design that uses the Active DDC block?

    ---

    regards,

        Igor