DS90UB949-Q1: Link to Deserializer is lost if Pixel clock / TMDS Clock is above 100MHz

Hello Moamen,

are you using our EVMs for your tests or using your own boards?

Is this issue seen on just one board or have you tried different bards?

Which cable length are you using? Can you try another cable? Another cable length, shorter or longer?

Have you measure the TMDS clock once it is 142MHz to make sure it is stable and has no jitter?

Hello Hamzeh,

First thank you for your reply and your will to support.

I'm using my own boards, I currently have 2 boards and both show the same issue.

I've tried 5m and 10m STP cable, the result is the same.

but I don't think it is a cable issue because the same cables is used for the combination 947 948 as mentioned above and it works fine.

I've not measured the TMDS clock, but at this state I read the status over ALP and:

• - the frequency is detected correctly.
• - all the following flags are set to True:
  • TMDS_VALID
  • HDMI_PLL_LOCK
  • FREQ_STABLE
• But the following Flags are false:
  • FPD3_LINK_RDY
  • FPD3_TX_STS

so somehow the FPD link is not initiated

Best Regards

Moamen

Hello Moamen,

can you please send register dumps from both devices, in a normal working mode (CLK below 100MHz), and in not okay mode (CLK above 100MHz)?

Also, if possible, to provide a register dump from the 947 where the CLK is above 100MHz.

Hello Hamzeh,

Here are the requested Register DumpsRegister_Dumps.zip

Best Regards

Moamen

Hello Moamen,

I will review and get back to you!

Hello Moamen,

I have reviewed and compared between UB947_OK_60Hz and UB949_NOK_60Hz.

949:
reg 0x0A = 0x4F -- number of BC CRC errors
reg 0x1F = 00 -- Frequency counter value is 0
reg 0x2B[3] = 1 -- FIFO underflow
reg 0x5A[6] = 0 -- No valid input has been detected!
reg 0x5F = 0x92 -- HDMI CLK = 146MHz
reg 0xC4 = 0x08 -- RX LOCK not detected.

Please double check if the DES is also set in the right MODE and for Dual lane configs.

Hello Hamzeh,

The DES is set in the right configuration.

I've been investigating further on the issue the past days, but I still can't get to the root cause of the problem.

Just a bit more info about my custom hardware:

- I have a transmitter card where I have 1x DS90UB949 and 1x DS90UB947 which are connected to the video sources

- the Receiver card has 2x DS90UB948, each connected to one of the above serializers

I've been checking the signal quality detected by the DES Chips over the CML loop through output and I've noticed that the DES connected to the 949 has a much worse signal.

I'm now using a shorter 2m cable for this test. along with the other 5m/10m cables.

Screenshots of the eye_diagrams are attached, the 949 shows a very narrow eye opening compared to the 947 even at lower frequency.

Snapshots.zip

As you spotted out in your reply above, it seems that once the 949 switched to the higher frequency the Back channel fails completely and the DES loses lock to the incoming signal. I think at the higher frequency the eye will be completely closed and the DES can't decode the signal anymore.

and now I'm not sure if this is an issue at the 949 Chip or at my layout. Since I've seen that there is a 949A version which is designed to work at higher frequencies.

Unfortunately I don't have access to your evaluation kits now to check this.

would it be possible if you send me a similar eye diagram from your evaluation kit? or at least a snapshot from the ALP showing the HDMI tab while a link with 1920x1080 at 60Hz is established between a 949 and 948?

Thank you very much for your support

Best Regards

Moamen

Hello Moamen,

as said, the UB949 does support PCLK = 170MHz in dual mode. So, I do not see any reason why it should not support your signal with 142MHz.

I really suspect a layout/link issue on the higher frequency ranges. 100MHz PCLK means 100x35 = 3500Mbps which is 1750MHz = 875MHz per link, while using 142MHz PCLK means 1.242GHz per link.

I would suggest you measure the Return loss and insertion loss on your link and see if that is still compliant for the upper frequencies.