SN65DP159: SN65DP159RGZR

Hi,

1.Can I please take a look at your schematic?

2. Does this issue happen with multiple sinks or a particular sink?

3. If measuring the DP159 clock output, are you seeing ~150MHz clock output?

4. Can you use an I2C controller to read out the DP159 registers?

If the DP159 EQ_SEL is set to NC, the DP159 EQ will automatically adapt with the minimum EQ being 2dB. The 2in trace at 3GHz Nyquist frequency is ~1.2dB. so 2dB EQ will over-compensate the 2in channel loss. I will try to disable the GPU pre-emphasis or set it to 0dB.

When you switch between HDMI1.4 and HDMI2.0, did you disable the GPU data and clock output first, make sure the TMDS_CLK_RATIO_STATUS is being clear/set correctly first, and then enable the output? 

Thanks

David  

Hi David, sorry for the late reply on this! I have prepared some answers to your questions below:

1. Yes, I have attached the retimer sheet below

2. This issue occurs on multiple sinks

3. Measured Output clock frequency is 148.49MHz

4. Here is the register dump after disabling eq starting at address 0x09h: 06 02 1A 61 01 00 0F 00 00 00 00 00 80 00 00 00 00 00 00 00 00 00 00 0A

Question: Could you also help us identify the part number of the USB to I2C controller that we can use to capture the received eye?

HDMI_Retimer_Sheet.pdf

Hi,

1. Are you controlling the DP159 in I2C or GPIO mode? On the schematic, you need to change the pullup resistors from 10k to 65k.

2. Since you are using the DP159 to level shifting the DDC bus between the GPU and the sink, can you check and see if the GPU supports clock stretching? 

3. In the I2C mode, please write 0x01 to register 0xFF, and then dump register from 0x01 to 0xB1.

4. If you enable the DP159 adaptive EQ (EQ_ADA_EN and EQ_EN bit are set to 1), are you able to get a video out to a sink?

5. Can you set the DP159 DEV_FUNC_MODE to 0x00(Redrive mode) and see if you are able to get a video out to a sink?

6. If you toggle HPD_SNK, are you able to get the sink to show the video?

To capture the eye requires the EyeScan SW and TUSB3410. The DP159 EVM has a built-in USB to I2C function using the TUSB3410, so you can use the EVM and then blue wire the I2C bus from EVM to your board to capture the eye.

Thanks

David

1. We are controlling the retimers through I2C currently. For BOM simplification reasons we were hoping to use 10K expecting them to be stronger than the recommended 65K. Is 65K truly required when we are relying on resistor straps to configure the part?
2. We haven’t been able to verify that the GPU supports clock stretching. However, we have verified that the sink is being correctly configured for HDMI2.0 mode using an Aardvark i2c controller. We are still trying to get confirmation of I2C clock stretching support in the GPU.
3. Register dump attached.
4. No video with adaptive eq, fixed eq (with 0db and 2db settings) or with eq completely disabled. We have also tried all of the eq settings with various de-emphasis settings on the GPU. Including no de-emphasis.
5. Still working on this. we’ll be able to provide this data point tomorrow.
6. Still working on this. we’ll be able to provide this data point tomorrow.

Questions:

• Do you have documentation describing the page 1 registers?
• Do you have any information on how to acquire the received eye without using TI’s EyeScan tool?
• We do not currently have and the DP159 EVM, does TI offer a USB to I2C pod supported by the EyeScan tool. We found the following eval board TUSB3410UARTPDK (www.ti.com/.../TUSB3410UARTPDK) , would this work with modifications. I realize we may need to update the firmware as described in the following post (https://e2e.ti.com/support/interface-group/interface/f/interface-forum/904650/sn65dp159-tusb3410-firmware-for-eyescan-tool) and may also have to remove the RS232 transceiver.

      00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
0x00: C3 01 3F 00 A0 00 00 00 01 00 00 33 00 00 11 00
0x10: 0F 30 00 07 01 00 00 00 00 00 00 00 00 00 00 00
0x20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x30: 07 30 08 00 00 00 00 00 09 00 08 08 04 06 00 00
0x40: 80 80 80 80 E8 00 00 00 80 F0 80 FF 03 00 00 70
0x50: 00 00 00 00 00 00 00 00 00 00 00 00 40 40 40 40
0x60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x80: 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0xA0: 00 00 11 00 00 00 00 00 00 00 00 00 00 00 00 00
0xB0: 5E 82 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Hi,

You can use the TUSB3410 with the updated firmware for the EyeScan SW. Would you please accept my friendship request so I can send you the firmware?

Looking at the Register 1 dump, Register 0x00 returns a value of C3 indicating the DP159 is in retimer mode and PLL is locked. Register 0xB0 value of 5E indicates roughly the input frequency is 5*25+25 = 150MHz, which is correct. Register 0xB1 bit 7 is 1, indicating the DP159 is detecting the input clock.

Out of curiosity, what is being connected to the DP159 output? Is it possible that the lane order gets swapped? Given that HDMI1.4 works, I don't think this is being the case, but want to double check. 

Thanks

David  

Hi David,

Ok thank you I have accepted your friend request and we have ordered the TUSB3410UARTPDK. We are hoping to start capturing the received eye either tomorrow or early next week. 

We have connected the retimers to various monitors including LG (34BK95U) and Dell (S2721Q) 4k monitors. We have also connected the outputs to the GoFango PRO-HDMI2Gen video analyzer and the Lecroy 780E video analyzer. To the best of our knowledge we would not expect any lane swap to occur or be needed. This should be a straight through connection. 

As for your suggested test in the previous reply (5 & 6), unfortunately we do not get video on the sink with the device setup in Redriver mode and toggling HPD_SNK also does not make a difference for us. 

If you have any other ideas/suggestion we welcome them and thank you again for your current effort in helping us with this!

Hi,

I sent you the TUSB3410 firmware in a private message, please check.

So far, I don't see an issue with the register dump or the eye diagram. The clock frequency and the ratio bit are also correct. Can you check and see if you are enabling the scrambling of the data? Scrambling is required for data rate > 3.4G.

Thanks

David

Hi David,

Thank you for providing us with that firmware! We were able to update the device and are now using it to capture the received eye at the retimer. I have some updates to what we have observed so far below:

Currently we are able to view outputs on the sinks as long as the resolution is capped to HDMI1.4 data rates but we do not get any video on the sink when running HDMI2.0 data rates.

We have observed, while using TUSB3410, that for HDMI1.4 data rates the retimers are completing TMDS lane deskew.

However, the retimers are unable to complete TMDS lane deskew when running HDMI2.0 data rates. The received eye for both cases look very similar so we were surprised that we did not see any output on the sink. 

I have attached some captures showing the received eye and status registers for both the passing(clock @300MHz and below) and failing cases(clock @346MHz and above).

What could cause the retimers to fail completing the TMDS lane deskew and what impact does this have on the outputs of the retimer?

Received eye @300MHz

Status/Control Registers @300MHz

Received eye @346MHz

Status/Control Registers @346MHz

Hi,

Something is not right here. If the clock is 346MHz and the TMDS_CLK_RATIO_STATUS is 1/40, the actual data rate on each lane = 346 * 40 = 13.84G higher than what the DP159 can receive, this can cause the DP159 not able to de-skew the input data.

For HDMI2.0, the clock rate is around 148.5MHz, which will give you around 6G data per lane.

Thanks

David 

Hi David,

Sorry we are used to dealing with the GPU and we were referring to pixel clock rather than the TMDS clock rate. The TMDS clock rate at the HDMI2.0 resolution is about 86.6MHz.

It appears that the retimers are unable to complete the TMDS lane deskew whenever we turn on data scramblers as required by HDMI2.0. Have seen issues with the enabling of data scramblers before? 

In order to test a pixel clock of 346.5MHz, just above the HDMI2.0 crossover point, we are using a resolution of 1920x1080@144hz.

If we disable data scramblers so the retimer can successfully complete the lane deskew, we can get video on the sink at pixel clocks of 346.5MHz which is an HDMI2.0 rate. However, if we re-enable data scramblers the retimers cannot complete the lane deskew and we do not get video. The enabling and disabling of scramblers is the only change the we are making between the working and failing cases at this data rate. 

HI,

If you bump the resolution up to 4k@60Hz, do you still see this DP159 dependency on the scrambler being enabled/disabled?

Thanks

David

Yes we still see this dependency at 4k60. 

Hi,

If you set the APPLY_RXTX_CHANGES bit, is the DP159 able to complete the de-skew?

We tested the DP159 de-skew function with and without scrambler on, and the de-skew always works.

And when you switch between different resolution, did you turn off the output before switching the resolution?

Thanks

David 

Hi David,

Thank you for your assistance with this matter so far. Since the last update, we have discovered there was an error with the configuration of our Scramblers that caused bad data being transmitted which prevented the Retimer from completing the lane deskew function. We now have video working up to a pixel clock of 500MHz and any pixel clocks higher than this lead to artifacts and screen tearing. 

We still believe that we may have a signal integrity issue between the GPU and Retimers. We are seeing some weird behaviour with the EyeScan tool while using the tool to capture the received eye to help debug this problem. From the image below, it appears there is a discrepancy in the generation of the received eye.  It appears that the light blue line hit a floor while the yellow line hit a ceiling. After this brief interruption, the data resembles what we would expect from the rest of the eye. Also notice that the eye seems to be shifted to the left instead of being centered. 

This is a capture of eyes as we move from 300MHz up to 550MHz pixel clocks. This shows that as the speed increases, the eye keeps shifting to the left and at a pixel clock of 550MHz the discontinuity in the eye is introduced. We get this type of discontinuity in any eye capture at a pixel clock at or above 550MHz. I am not sure if this an error with the captured data or an error with the way the tool is rendering the data but I do not believe this is an accurate representation of the data. Is this something you have seen before? Or are we missing a setting somewhere in the tool when capturing eyes at these higher pixel clocks? Thanks again for your assistance with this issue and looking forward to hearing your thoughts. 

Hi,

This is an issue with the EyeScan SW, please take a look at page 11 of the EVM user guide, https://www.ti.com/lit/ug/sllu228a/sllu228a.pdf.

Are you using the DP150 adaptive equalization in your current testing?

Thanks

David

Hi David,

thank you for the quick response and the explanation! One more question, it also appears that the Unit Interval is not being correctly calculated past about a 300MHz pixel clock. Is this why the eye is about half the size you would expect when testing at a pixel of 600MHz? Should we be reading the eye width directly or should we be scaling it to understand the actual quality of the eye? We have equalization disabled during these tests since our trace length is so short. 

Thanks,

Amadou

Amadou

Correct, the unit interval is not being scaled properly in the Eye Scan SW. The SW allows people to review general eye quality per lane at the receiver, but it's not meant for a detailed signal integrity analysis. 

Can you try to enable adaptive EQ? You can disable DP159 EQ, but are you enabling any GPU TX signal conditioning function to compensate for the short trace between the GPU and the DP159.

Thanks

David 

Hi David,

Thank you for clarifying that for us. The below screenshot (raw data also attached) is a comparison of the received eye for adaptive eq vs eq off. In both of these configurations, we found that the settings of max Vswing and lowest de-emphasis on the GPU gives us the widest eye at retimer inputs. According to this capture, there is very little difference between eq off and adaptive eq. If you think enabling adaptive eq is the best settings for our configuration then we are happy to enable adaptive eq. From our research this eye should have enough height and width to properly pass video through the link. What are you thoughts on this? We are open to any additional feedback you may have and thanks again for your help with this issue.

Current Retimer register settings starting at address 0x09h: 0x06 0x33 0x1B 0x61 0x00

BestEyeSettings_Adeq_vs_eqoff.zip

Hi David,

Yes we are still getting compliant results when we run the compliance test software with these settings and the clock frequency is also correct (see capture of test results below). We'll be probing the input side of the retimer to verify the clock frequency and will send you those results. 

Thanks,

Amadou

Amadou

If you configure the DP159 into redriver mode, do you still have the same issue when the clock rate goes above 550MHz?

Thanks

David