TLK10232: Communication error

Takanori-san,

Thank you for all the information. Has the customer tried to tune HS_SERDES_CONTROL_x during this test to eliminate error? Is this a optical application? Just to confirm you have tried a "swap" test, where you replace a functioning part in a functioning system with a failing part part to confirm that the problem "follows" the device? Please see answers/questions to your questions below.

1. Is there any trouble similar to the above in the product? Does TLK10233 have any issue?

• There is no know issue with TLK10232 across temperature. What temperatures are the errors seen at?

2. The error frequency depends on the temperature at startup. Does the IC calibrate at startup?

• At startup the IC will have internal PLLs lock on to input reference clocks. There is also a calibration done to compensate for input voltage offset at the receiver after the internal PLLs have locked and the receiver is enabled. The customer can disable this calibration via the HS_AZCAL register to see if this is what is causing issue?

Hi Malik-san

Please see the customer's feedback below and let me know your advice.

Has the customer tried to tune HS_SERDES_CONTROL_x during this test to eliminate error?
=> No. They use default value.

Is this a optical application?
=> Yes

Just to confirm you have tried a "swap" test, where you replace a functioning part in a functioning system with a failing part part to confirm that the problem "follows" the device?
=> No. It's because they have only a few devices and it might have risk to replace.

What temperatures are the errors seen at?
=> They used point cooler for low temp test and heat gun for high temp test.

The customer can disable this calibration via the HS_AZCAL register to see if this is what is causing issue?
=> They will try it.

The register value to change from default below.

#1
PHY Add：0x00
Dev Add：0x1E
Reg Add：0x0000
Write Data：0x8610

#2
PHY Add：0x00
Dev Add：0x1E
Reg Add：0x0000
Write Data：0x0E10

#3
PHY Add：0x00
Dev Add：0x07
Reg Add：0x0000
Write Data：0x2000

#4
PHY Add：0x00
Dev Add：0x01
Reg Add：0x0096
Write Data：0x0000

#5
PHY Add：0x00
Dev Add：0x1E
Reg Add：0x0004
Write Data：0xD500

#6
PHY Add：0x00
Dev Add：0x1E
Reg Add：0x000E
Write Data：0x0008

The result after confirming the waveform

1. The timing for MDIO and MDC are not violated on the datasheet.
2. The quality of waveform for XAUI is no problem. Input CLK is stable when RST on PHY de-assert.
3. The each supply voltage is stable.

Best Regards,
Takanori Yuzawa

Hi Malik-san

The customer is considering that the error is related to incorrect AGC(Auto Gain Controller) behavior because of the customer's evaluation.
What is the reason for incorrect AGC behavior? And also, does AGC restart by DATAPATH_RESET setting?

Please see the customer's evaluation result below.

#1: PHY Add：0x00　Dev Add：0x1E　Reg Add：0x0009　Write Data：0x0388
Detected error when set HS_AGCLOCK_OVERLAY and monitor LOSA and then the PHY is cooled with a point cooler.
If it keeps to cool then LOSA keeps high. If not keeps to cool then LOSA keeps low.
It does not change the level when the value of HS_AGCCTRL(HS_SERDES_CONTROL_2) change.
Only if it set Force the attenuator off, LOSA keeps high.

#2: PHY Add：0x00　Dev Add：0x1E　Reg Add：0x0009　Write Data：0x0390
When set HS_INVALID_CODE_OVERLAY and monitor LOSA then the error often occur.
When cooled PHY and set DATAPATH_RESET then the error increased.
When warmed PHY and set DATAPATH_RESET then the error decreased.

#3: PHY Add：0x00　Dev Add：0x1E　Reg Add：0x0003　Write Data：0xA848 or 0xA808 or 0xA888 or 0xA8C8
When set all HS_AZCAL then the behavior did not change.

Best Regards,
Takanori Yuzawa

Takanori-san,

I am continuing to investigate the issues here, does the customer know the specific temperatures they are cooling and heating the device to while testing? This information is important to understanding what may be happening. Also is the customer saying that the AGC never locks (LOSx = low) during testing  or becomes unlocked when cooled regardless of how long it has been running or is this test only conducted at startup? Customer could also monitor HS_AGC_LOCKED bit to determine when the AGC becomes unlocked during their test. 

Is HS_AGCCTRL[1:0] = 00 is device setup? Does the customer still see issues if they force the attenuator on (HS_AGCCTRL[1:0] = 11)?