DS110DF410: DS110DF410SQ Retimer with SFP+ DAC cable inconsistency

Hi Sujith,

What is the length and insertion loss of the copper cable?

Are you using the same retimer configuration with both the copper and fiber cables?

Could you share a register dump and BER for both cables? If possible, please also share the BER during the case where the video is stuck with the copper DAC cable.

Thank you,

Evan

Hi Evan,

Thanks for the reply.

Please find requested inputs.

1)  What is the length and insertion loss of the copper cable?
(Ans):  Please find the attachment. kindly refer page number: 3 (1M 30 AWG: 74752-1101). We are using 1 meter cable for testing. 

2) Are you using the same retimer configuration with both the copper and fiber cables?
(Ans):  Yes.we are using same retimer configuration for both the copper DAC cable and fiber cables.

3) Could you share a register dump and BER for both cables? If possible, please also share the BER during the case where the video is stuck with the copper DAC cable.

(Ans): Attached retimer configuration register sets. Here we are running Xilinx 7 series transceiver video IP for testing. We are getting BER while video was stuck.

/cfs-file/__key/communityserver-discussions-components-files/138/iWave_5F00_retimer.c

/cfs-file/__key/communityserver-discussions-components-files/138/EE_2D00_74752_2D00_1497_2D00_001.pdf

Regards,
Sujith M

Hi Sujith,

The .c file you have shared only shows configuration details for the retimer - are you able to share a register dump for both cables?

If this is on a linux system, i2cdump() may be helpful for this.

Thank you,

Evan

Hi Evan,

Sorry for the delayed reply.

Please find the excel sheet with register dump of both the optical and copper cable working and non-working stages.

/cfs-file/__key/communityserver-discussions-components-files/138/retimer_5F00_debug.xlsx

Waiting for your inputs.

Regards,
Sujith M

Hi Sujith,

Thank you for the detailed register dump and system information.

The VEO values in the dump indicate 422mV for fiber, and 118mV for copper in the failed case. We typically see at least 200mVpp for VEO, so I recommend tuning the EQ settings for the copper case to see if performance is improved.

At div8 subrate, the CTLE setting is taken from 0x3A rather than 0x3 (section 8.5.8 has detailed explanation for this).

To apply a fixed CTLE setting in this case, modify the value in 0x3A.

To enable EQ adaptation for div4 or div8 subrates, write 0x6F[7] = 1.

Regards,

Evan

Hi Evan,

Thanks for your valid input.

As per your input, we did two iterations. Attached latest Excel sheet with test observations.

/cfs-file/__key/communityserver-discussions-components-files/138/Retimer_5F00_Register_5F00_Dump.xlsx 

1) Test -1
Followed Section 8.5.8 and updated the binary with the below changes.

Address New Written Value   Old value
0x31 :        0x00                      0x20
0x2D :       0x88                      0x80
0x40 :       0x01                       0x00
0x13 :       0x34                     0x30

We tested with the above-updated binary and it was working fine.

2)Test -2
We took the same binary which we tested @ Test -1, Here we did small changes (Only Limiting mode enabled)

Address   New Written value       New changes @ Test -2
0x31 :           0x00                             //Mask //Not Enabled
0x2D :          0x88                            //Mask //Not Enabled
0x40 :          0x01                             //Mask //Not Enabled
0x13 :           0x34                              //Enabled //Limiting mode

Using the above-modified binary we tested the system; we didn't get any issues. It was working fine.
After enabling the Limiting mode, we could see VEO read register showing good response than the previous binary.
Could you please confirm whether can we use these limiting mode settings for all channels instead of fine-tuning individual channels?
Moreover, we would like to understand more about on Retimer Limiting mode features, can you explain the same?

Regards,
Sujith M

Hi Sujith,

If you are seeing improved performance in all cases and channels with limiting mode enabled, then this setting is a valid alternative to fine-tuning individual channels. Please note that 0x6F[7] = 1 can also be written to enable automatic EQ adaptation (another alternative setting for div4 and div8 subrates).

Limiting mode changes the fourth stage of CTLE to become a limiting stage rather than a linear stage. This setting is not recommended if the DFE is also active for adapt modes 2 and 3.

Thank you,

Evan

Hi Evan,

Thanks for the reply.

Please find my inline reply.

1) If you are seeing improved performance in all cases and channels with limiting mode enabled, then this setting is a valid alternative to fine-tuning individual channels. Please note that 0x6F[7] = 1 can also be written to enable automatic EQ adaptation (another alternative setting for div4 and div8 subrates).
Ans) Ok. In retimer datasheet 0x6F register is "RESERVED " There is no description and control. We tried to set it as 1 for 7th bit, while reading back the register we are getting 0x0. Writing is not happening for this register. How can we enable these alternatives settings?
 

2) Limiting mode changes the fourth stage of CTLE to become a limiting stage rather than a linear stage. This setting is not recommended if the DFE is also active for adapt modes 2 and 3.

Ans) Ok.We are running retimer register set with default configuration,

By default,

    1) Adaption mode :1

   2)We are not writing any values to 0X1E register and its associated register sets. Basically, it's running in default config. So that DFE feature in power            down mode.

Also, could you please confirm can we apply this limiting mode in final binary, is there any issue or drawback for this mode if we run with Mode 1?

Regards,
Sujith M

Hi Sujith,

Yes, for the default configuration with adapt mode 1, limiting mode is not a concern as DFE is not active.

For automatic EQ adaptation from 0x6F[7], are you selecting a channel register set to write to beforehand? E.g. 0xFF = 0x04 for writing/reading to channel 0. 

Thank you,

Evan

Hi Evan,

Thanks for confirming.  

We haven't written any value to channel register. If we are writing to channel registers, then automatic EQ adaptation will be only specific to individual channel, right?

Can we enable automatic EQ adaptation for all channel registers?

Do you know, what would be the cause of this eye VEO variation in the optical and copper medium?
Instead of tuning retimer ,how can we improve the eye VEO in Copper medium?

Regards,
Sujith M

Hi Sujith,

Sujith Mohandas said:

We haven't written any value to channel register. If we are writing to channel registers, then automatic EQ adaption will be only specific to individual channel, right?

Yes, each time 0x6F[7] is written, it will apply to the specific channel that is selected prior with register 0xFF. Please refer to Table 15 for channel select settings. Here is the recommended register sequence to enable automatic EQ adaptation on all channels:

0xFF = 0x0C (All writes target all channel register sets, all reads target channel 0 register set)

0x6F[7] = 1'b1 (Enable automatic EQ adaptation on all channels)

Sujith Mohandas said:

Do you know, what would be the cause of this eye VEO variation in the optical and copper medium?
Instead of tuning retimer ,how can we improve the eye VEO in Copper medium?

I suspect the insertion loss of the copper cable to be the cause of the VEO variation. I'm unsure if over-EQ or under-EQ is the issue in this case - if possible, please try cables of various length and note the changes in VEO as a result.

Thank you,

Evan