• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 2633 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: TMDS channels not correctly de-skewed after video format change

Martin Seeger
Expert 5371 points
Part Number: TMDS181

Dear Team,

our customer is facing a problem with the HDMI Input / TMDS181 on their prototype:

Sometimes it happens (after a video format change) that the TMDS channels are not correctly deskewed, and that the Deskewing even is different during the first active video line, compared to the other active video lines.

Please find below some scope images showing this malfunction on a video format :  1280 x 720 p @ 60Hz. (which was decoded as 1280 x 718 p @ 60 Hz by the TMDS decoder).

Please find more information below from the customer (high resolution of the graphs share via TI box).

1) HDMI Input:

The skew for the first line on the input of the TMDS181 looks like this (C1 = Vertical Sync, C2 = Horizontal Sync, C3 = TMDS data (measured with differential probe)).

As you can see there is as good as no skew between the 3 different clock lines (the delay of 1.1051 us is referenced to the rising edge of the Horizontal sync that was decoded by our TMDS decoder).

2) HDMI Output

When we take a look at the same signals at the output of the TMDS 181 for the first active line we can see this.

As you can see, there is as good as no skew between TMDS0 & TMDS2, but there is large skew between TMDS1 and the other channels of about 69ns (at a TMDS clock of 13ns this is about 5 TMDS clock cycles).

 

3) 2nd Video Line

When measuring the second active video line, we can see that the skew has changed.

Now there is almost no skew between the three channels. So the skew seems to have been changed between the first and the second active line.

This behaviour is confusing our TMDS decoder, making it to lose the first 2 active video lines.

Is this behaviour something that is known by TI engineering? What could cause it, can it somehow be prevented?

Be aware that we are using the TMDS181 in reclocking mode over the full range. I’m not sure if this has something to do with it?

When this happens (this only happens intermittently) it can be cured by rewriting the apply_RXTX_changes register in the TMDS181. Then all outputs are aligned perfectly.

Our problem is that if it is going wrong, we can not easily detect this, making it unclear when we would need to rewrite this bit and when not. Is there a way to read out the amount of skew at the output of the TMDS181 using the register interface?

Thanks and best regards

Martin

  • 0
    TI__Mastermind 23815 points
    Hi Martin,

    I assigned this ticket to the right applications engineer.
    You will have feedback soon.

    Regards
  • 0
    TI__Guru 60865 points
    Hi Martin,

    Is HPD toggling H->L->H during the video format change? It appears that the TMDS181 may still be in the clock frequency detection / acquisition stage during the first active lines, and setting apply_RXTX_changes forces the CDR initialization to restart. Can they try setting SIG_EN so that the TMDS181 disables its outputs until the initialization is complete?

    Also, does this problem just occur on the first set of video data or is there a consistent skew issue on Channel 1?

    Additionally, can they provide the date code on the TMDS181 device?

    Regards,
    JMMN
  • 0 in reply to JMMN
    Prodigy 190 points
    Hi JMMN,

    Martin asked me to reply directly into this forum, since he is on holiday now. I reported this issue to him.

    The HPD is not toggling during the format change.
    I will retry to reproduce the problem after having written a '1' in the SIG_EN register. What do you expect to see with this test? I'm asking this, because I have filtered out all other issues during my format switching test, It only stops when the detected format is missing one or two lines. If for some reason the format can not be detected (I suppose this is what you want to accomplish) because the outputs of the TMDS181 do not get released due to the TMDS181 being stuck in frequency detection/acquisition stage, my test will not detect this.

    This problem is consistent, in this manner, that the skew is only there for the first active video line in a frame (see second set of scope images). starting from the second active videoline (third set of scope images) upto the last one in the same frame, the skew seems to have disappeared. This behaviour repeats for every frame, until the apply_RXTX changes register is rewritten.

    I'm not sure where the datecode is located, but these are the markings on the device:
    TMDS181

    TI 64I
    CG8L G4

    Regards,
    Stefaan
  • 0 in reply to Stefaan
    Prodigy 190 points
    Hi JMMN,

    I have tested with the SIG_EN register set to '1', but this does not solve the problem.

    Regards,
    Stefaan
  • 0 in reply to Stefaan
    TI__Guru 60865 points
    Hi Stefaan,

    My initial thought was that this had something to do with the TMDS181 device outputting invalid data before the clock had a chance to lock to the new format frequency. The data you provided shows a very different problem where the first active line of video data is consistently skewed. This seems much more likely to be a TMDS encode / decode issue since the TMDS181 is unaware of the data is sends and we cannot duplicate a condition where only one line of a frame is consistently affected by skew. If there was a Channel 1 skew issue I would expect to see flickering video or consistent drops, not just one line of a frame affected. Does the sink toggle HPD between format changes or is it a running change?

    Regards,
    JMMN
  • 0 in reply to JMMN
    Prodigy 190 points

    Hi JMMN,

    The sink does not toggle HPD between format changes, it is indeed a running change.

    I will summarize the conditions under which it happens below:

    1) 0x23 is written to register 0x00 in Page1 to set A_LOCK_OVR

    2) The device working function mode is changed to mode 3 (Retimer mode across full range 250 Mbps to 6 Gbps.

    3) APPLY_RX_TX_CHANGES is written

    4) HPD goes from low to high

    These 4 steps are only performed once after the device has been powered up, not inbetween the resolution changes.

    During the test i run to reproduce the issue (which I have to be honest about, is not easy, it might take hundreds or even thousand of swithes befor the issue happens) i'm automatically cycling the source through a set of 4 resolutions: 1024x768@60, 1280x720@50, 1280x720@60 and 1280x800@60. Between each switch I wait 10 seconds to settle everything, and then I check the resolution after the TMDS decoder.

    A few remarks:

    • I tried the same test with the TMDS181 in default working function mode 1 (Automatic redriver to retimer crossover at 1.0 Gbps) and in this mode I am not able to reproduce the problem (I suppose, because there is no deskewing in redriver mode?)
    • Concerning the fact you mention that it is more likely to be a TMDS encode / decode issue, how does that explain that there is no skew at the TMDS181 input ( see my first three scope shots above) but there is the skew during the first active line on channel 1 at the TMDS181 output? (see second set of three scope shots above)?
    • Again Concerning the fact you mention that it is more likely to be a TMDS encode / decode issue, how does that explain that the skew at channel 1 disappears by only writing the APPLY_RXTX register in the TMDS181, and changing nothing in the source at that time?
    • This is more like a question to understand how things work: how can you deskew the three channels if the TMDS181 is not aware of the data that passes through it? What is used as a reference point to detect the skew at the input, and to know how much compensation is needed between the channels? I suppose there must be hardware that looks for an alignment character in the different datastreams?

    Kind Regards,

    Stefaan 

       

  • 0 in reply to Stefaan
    TI__Expert 5371 points
    Hi JMMN,

    I hope that you are doing fine.

    May I ask if you have found out more / had the chance to have a look at Stefaan's question?

    Looking forward to your feedback.
    Best Regards
    Martin
  • 0 in reply to Stefaan
    TI__Guru 60865 points
    Hi Stefaan,

    Apologies for the delayed response. This is not an issue we have been able to duplicate in the lab. We would anticipate that this kind of issue may occur if the clock rate was changed without an HPD toggle and the clock ratio was modified (SCDC register access was not applied), or even if there was a large change in the data rate that was not sensed properly. It is surprising that this issue is occurring between resolutions with similar data rates.

    Responses to your questions:
    - Yes, you are correct there is no deskew in redriver mode
    - Is the HSYNC/VSYNC the same on both sides of the TMDS181? I would have assumed this would come from the TMDS decoder?
    - Setting the APPLY_RXTX bit has the effect of reconfiguring the RX and the TX blocks, so any kind of alignment issue in the system could be resolved when it is asserted.
    - It was incorrect to state that the TMDS181 is unaware of the data that is being retimed. It does look for the control characters to do the deskew, what I meant was that the TMDS181 is unaware of the data content of the lanes. This is why it is confusing that this is a persistent issue on a specific lane during specific active lines.

    I have identified a possible further debug option that may help to identify root cause. I will communicate it directly.

    Regards,
    JMMN