DS280DF810: PRBS-31 Testing error

Hi,

Have you tried using the PRBS checker on the retimer to determine whether the errors are occurring on the ingress or egress signal chain?

Thanks,

Drew

Hi Drew,

Yes, we did try to check the PRBS on re-timer and Most errors are occuring in ingress path i.e. ASICS to RETIMER .

Request you to solve this issue asap.

Thanks,

Aman

Hi Aman,

Do you have an estimate for insertion loss from ASIC to RETIMER?  It looks like the retimer has selected CTLE index 0, which applies around 8-9 dB of boost.  Want to confirm that we are not under equalizing the signal.

Do you see any change in the retimer eye opening when you enable both ports compared to enabling just a single port?  In the register dumps you shared, the eye openings looked pretty good.  Empirically, we generally observe good performance for HEO/VEO of at least 0.4UI/200mV.  It's surprising that you are observing errors with your current eye openings.

Have you tried adjusting ASIC TX FIR settings?

I'm wondering if there's a chance that enabling the second port on the ASIC is somehow increasing the jitter in the system.  If this is the case, increasing CDR bandwidth could help.  Can you try some different CDR bandwidth settings to see if this impacts BER?  You can set these via the low level page of SigCon Architect.

Information on adjusting CDR bandwidth is in section 7.31 of the programming guide.

Thanks,

Drew

Hi Drew,

We have estimated max 10dB of loss between retimer and asic.

Yes there is change in the eye opening when enabling all 8 channels in comparison with 4 channel

Yes I already tried set ASIC TX FIR, after setting the ASIC TX FIR we were able to reach at current state.

And, I tried the changing CDR bandwidth which improve the BER but still errors are there.

Is there anything else we need to take care off.

It's a request will you able to come on remote session for debugging the issue.

Thanks,

Aman 

Hi Aman,

We can meet to work on debugging this issue.  I'll work on coordinating a time with the field applications engineer supporting you.

How large is the change in eye opening when all 8 channels are enabled?

Would it be possible to compare die temperatures with 4 channels/8 channels?  I'm curious if there could be any correlation between temperature and performance.  You can use the procedure in section 2 of the application note below for this.

https://www.ti.com/lit/an/snla386/snla386.pdf

Thanks,

Drew

Hi Drew,

There is a significant change in HEO is observed i.e. upto value of 0.75UI.

Please, coordinate with the field application engineer for debug session that will be very helpful.

Meanwhile, I will measure and compare the die temperature.

Thanks,

Aman

Hi Aman,

0.75 UI variation seems incredibly large.  Often we don't see HEO values of 0.75 UI, so I'm a bit puzzled about how you're seeing that much variation.  Was this HEO as measured by DS280DF810?

Thanks,

Drew

Hi Drew,

That was a typo HEO variation value was 0.075UI. 

And, I tried to read the temperature value for a particular channel which  got the value of Reg_0x0D = 0x80 and Reg_0x0E = 0x93

On calculating this value using equation Tj = 314.08 C which is not the correct value I guess.

Most of the register bits used in the read channel temperature process are reserved in the programming guide SNLU182. Do you have the detailed register description for this?

Also. any update on the debugging session, this is blocking our production so please try to resolve the issue as soon as possible.

Thank,

Aman

Hi Aman,

I believe Selva set up a debug session for us, looking forward to talking with you soon.

Thanks for clarifying the variation in HEO.

It's strange that you observed such a high Tj.  Any registers marked as reserved are kept internal, so I don't have additional details I can share on this.  In general though, the descriptions for each step of reading junction temperature are an accurate description of each register write.  With this said, I have tried this procedure in the past and observed reasonable Tj values.

Thanks,

Drew

Hi Drew,

As per our remote session on 28-March. I hope you understand the problem clearly and discussed it internally. Please, Let me know if you have some helpful insight. Also, there were some following open points please comment :

• On performing temperature read operation after writing highlighted register value of Global Register 0xFF is getting updated automatically
• 
• On disabling the other 4 channels there were noticeable improvements in error 

Regards,

Aman

Hi Aman,

Thanks for meeting and for sharing the highlights of our meeting.  We have been out of office for the past couple days for holiday, thanks for your patience.  We are discussing this internally.

Thanks,

Drew

Hi Drew,

Please respond to below queries also,

• In SNLA_386 document there is some  typo error in attachment, It's is supposed to be DSAR[7:0] = Reg_0x0D[7:0] Please confirm.
• For section 3 TLR procedure we are setting LPF settings. Do we need to reset Reg_0x1F[3]=0 
• 
• 

Hi Aman,

• Yes this is correct, DSAR[7:0] = Reg_0x0D[7:0].
• Regarding Reg_0x1F, I see that we have a different description for this register on our internal register map that does not reference 0x9D. I've reached out to a colleague to see if they know the history of the conflict.  However, based on our internal register map, it appears 0x1F can be left at default.

Thanks,

Drew

Hi Drew,

Waiting for your response.

Thanks,

Aman

Hi Aman,

Apologies for the delay.

Instead of enabling 4 channels of a single port at a time, is it possible to enable 4 channels across two ports at a time?  For example, 2 channels of one port, and two channels of another port.  Under this condition, how does error rate compare to having a single channel or both channels enabled?  This will help us to better understand if the issue can be correlated with thermals.

Regarding additional CDR bandwidth settings, looking at the device registers, it seems like higher bandwidth settings should be possible.  You could try values beyond what is included in the programming guide to see if this improves the number of observed errors.

Thanks,

Drew

Dear Miller,

From analyzer it is not possible to turn off 2 lanes out of 4. 

And, for changing CDR bandwidth on what basis I should change the settings to higher loop bandwidth. Share some reference or example values.

Regards,

Aman

Hi Aman,

Drew is currently out of office. I expect he can follow up next week.

Regarding higher CDR bandwidth settings, I believe Drew meant that Table 7-45 of the programming guide does not show all possible settings. Based on 0x1C and 0x9E register fields, there are many higher bandwidth settings which can be programmed.

I created this table showing register values for charge pump settings up to 31. I believe this may be a good starting point for additional CDR bandwidth testing. Charge pump setting can be configured larger than 31 following the same pattern of register values.

Best,

Lucas

HI Lucas, 

I tried with other LPF settings as well, but unable to resolve the error.

It has already been a month, please help us to resolve the issue.

Regards,

Aman

Hi Aman,

There are a couple internal bias currents for the device.  Could you try adjusting these to see if they impact your performance?  Increasing the value of these fields increases the bias current.  I'm wondering if higher bias current might improve performance.

ch_reg_0x98[5:4]

ch_reg_0x98[1:0]

ch_reg_0x1A[7:6]

Thanks,

Drew

Hi Miller,

Register suggested are RESERVED in "DS2x0DFx10_SNLU182_Programmers_Guide", please suggest the tentive value.

Current value of the following  registers are 

ch_reg_0x98=0x0

ch_reg_0x1A=0x58

Regards,

Aman

Dear Miller,

Also, if there is any other updated programming guide, please do share with us.

Regards,

Aman

Hi Aman,

These are internal registers, so it is expected that they are marked as reserved.  The latest revision of the programming guide is revision H, and can be found on the DS280DF810 mysecure page.

Please try the following settings and see if they impact your performance:

ch_reg_0x98[5:4] = 2b01, 2b10, 2b11

ch_reg_0x98[1:0] = 2b01, 2b10, 2b11

ch_reg_0x1A[7:6] = 2b10, 2b11

Thanks,

Drew

Dear Miller,

As we have seen improvement after increasing CDR bandwidth, does this mean VCO noise is responsible for observed BER.

I am unable to find revision H programming guide on mySecure page, please share the guide if possible it will be very helpful.

Regards

Aman

Hi Aman,

I just granted you access to DS280DF810 mysecure.  Please let me know if you have any issues accessing it.

As we have seen improvement after increasing CDR bandwidth, this suggests that higher bandwidth is required to track the input signal.  This seems to suggest that input jitter is a contributing factor towards BER.

Did you see any change in performance by adjusting the bias currents I suggested?

Thanks,

Drew

Dear Miller,

Thanks, for the programming guide access.

I didn't seen any improvement in performance after adjusting bias current.

As far as I know input jitter is filtered by lowering the bandwidth of the PLL and VCO jitter is reduced by increasing the BW of the PLL.  But this for reducing clock jitter in clock devices, Is this hold true here as well?

Regards

Aman

Hi Aman,

I believe the concepts hold true here.  However, I think one additional thing to consider is the impact of input jitter filtering on the CDR system.  While lower bandwidth improves the jitter transfer to the output signal by filtering the input jitter, this also means that the input signal is not tracked as closely.  As a result, I think there could be a larger delta between when the CDR sampler samples the input data, and the ideal sample time.

Because of this, I think it's more challenging to draw a definitive conclusion on the exact mechanism through which increased loop bandwidth is improving BER.

The DS280DF810 has independent VCOs for each channel, so it's strange that enabling 4 vs 8 channels would have an impact on performance, unless there is some common factor like temperature, supply voltage ripple, etc.

Other customers have used DS280DF810 without needing to adjust loop bandwidth.

If I recall correctly, I believe you primarily saw errors from ASIC --> DS280DF810 connection.  If this is correct, is there any way to individually enable/disable channels on your ASIC?  Although this not work well for your analyzer measurements, you could measure BER on the retimer.  It would be valuable to understand if the better performance seen with just 1 port (4 channels) enabled can also be seen with 4 channels enabled over the two ports.

Thanks,
Drew

Dear Miller, 

I will try to disable channels on ASIC.

And, I have also measured the ripple on the Retimer power that is generated through TI LDO TPS7A7.which is well under the limit.

Also, as discussed earlier I am unable to measure channel temperature correctly. For that I am sharing the Retimer version ID please check weteher it is supported or not.

Device 1 

0xEF (TI device ID QUAD count) = 0x0c 

0xFE (TI vendor ID) = 0x03

0xF0 (TI version ID) = 0x30 

0xF1 (TI device ID) = 0x13

0xF3 (TI channel/share version ID.) = 0x00

Device 2

0xEF (TI device ID QUAD count) = 0x0c 

0xFE (TI vendorID) = 0x03

0xF0 (TI version ID) = 0x30 

0xF1 (TI device ID) = 0x13

0xF3 (TI channel/share version ID.) = 0x00

Regards,

Aman

Hi Aman,

Drew is out of office today and can get back to you next week.

I don't expect there to be an issue with temperature readback based on the retimer IDs you provided.

Best,

Lucas

Hi Aman,

Yes, this device version supports the temperature reading.

Below is a function I've used for successfully reading back temperature from DS280DF810, based on the Junction Temperature Readback Application Note.

Please note read modify write function uses i2c_rmw(register, value, mask) format.  The application note recommends delay of 200us, but if you're having issues, I'd recommend increasing the time to around 10ms to see if this changes your results.

def get_temp(u2a:USB2ANY_HSSC, adc_sample_time:float=200e-6):
    """
    Provide USB2ANY object
    Provide adc sample time [seconds] - recommended value 200us
    """
    u2a.i2c_rmw(0xFF, 0x10, 0xFF)   # Sel quad0 shared registers
    u2a.i2c_rmw(0x04, 0x40, 0x40)   # Reset quad0 shared registers
    u2a.i2c_rmw(0xFF, 0x20, 0xFF)   # Sel quad1 shared registers
    u2a.i2c_rmw(0x04, 0x40, 0x40)   # Reset quad1 shared registers
    u2a.i2c_rmw(0xFF, 0x10, 0xFF)   # Sel quad0 shared registers
    u2a.i2c_rmw(0x0F, 0x00, 0xFF)   # Enable temperature detection quad0
    u2a.i2c_rmw(0xFF, 0x20, 0xFF)   # Select quad1 shared registers
    u2a.i2c_rmw(0x0F, 0x00, 0xFF)   # Enable temperature detection quad1
    u2a.i2c_rmw(0xFF, 0x01, 0xFF)   # Disable broadcast write, select single channel r/w by 0xFC
    u2a.i2c_rmw(0xFC, 0x04, 0x0F)   # Select single ch (ch2)
    u2a.i2c_rmw(0x19, 0x01, 0xC1)   # Enable ch temp detection
    u2a.i2c_rmw(0x18, 0x01, 0x03)   # Enable ch temp detection
    u2a.i2c_rmw(0xFF, 0x10, 0xFF)   # Sel quad0 shared registers
    u2a.i2c_rmw(0x0C, 0x00, 0x38)   # Select ADC input
    u2a.i2c_rmw(0x0C, 0x02, 0x03)   # EN ADC
    u2a.i2c_rmw(0x0C, 0x04, 0x04)   # rst ADC
    u2a.i2c_rmw(0x0C, 0x00, 0x04)   # clr rst

    time.sleep(adc_sample_time)     # Precision is probably not good enough

    temp0 = u2a.i2c_read(0x0D)      # Read temp[7:0]
    temp1 = u2a.i2c_read(0x0E)      # Read temp [9:8]

    u2a.i2c_rmw(0xFF, 0x10, 0xFF)   # Sel quad0
    u2a.i2c_rmw(0x04, 0x40, 0x40)   # rst quad0
    u2a.i2c_rmw(0xFF, 0x20, 0xFF)   # sel quad1
    u2a.i2c_rmw(0x04, 0x40, 0x40)   # rst quad1
    u2a.i2c_rmw(0xFF, 0x01, 0xFF)   # En single ch r/w
    u2a.i2c_rmw(0xFC, 0x04, 0x0F)   # Sel ch2   
    u2a.i2c_rmw(0x19, 0x00, 0xC1)   # disable ch temp detection
    u2a.i2c_rmw(0x18, 0x00, 0x03)   # disable ch temp detection

    temp_dec = (temp1 & 0x03)*256 + temp0
    temp = 0.73*temp_dec - 340

    return temp

Thanks,

Drew