DS110DF111: the SFP optical port fails to be inserted and removed repeatedly.

Hi Bin,

I wouldn't expect repeated insertion/removal of the optical module to create any issues on the retimer level. I have several questions to better understand the issue.

1. Does the module need to be inserted and removed at a certain speed or for a certain duration to reproduce the issue?
2. Has the issue been reproduced across multiple system units?
3. Is the module transmitter connected to INA?
4. Is the customer using any custom configuration on the LOS/INT# pin? Or is it active low when a valid signal is present (default)?
5. What is the LOS/INT# pin behavior throughout the duration of the test?
6. Can the customer repeatedly read channel registers 0x02 and 0x54 throughout the duration of the test and report the values seen?
7. Has the customer started any investigation to see if the issue is occurring at the module?

Best,

Lucas

Hi Lucas,

When the optical module is inserted and removed repeatedly and the optical port links down, the system needs to reboot before the optical module recovers

Now, I will answer your questions
1. The problem does not need to be repeated at a certain speed or time, sometimes it will be repeated after plugging once, sometimes it will be repeated several times
2. Other system units have not been tried
3. According to the schematic diagram, it is connected to INA
4. Default configuration is used instead of custom configuration
5. What does this action mean?
6. When normal and recurring problems, the values of 0x02 and 0x54 are both 0x00, is there a problem with my operation? Do I need to write 0xff to select the channel first
7. I am not sure whether this is related to DS110DF111, but according to the schematic diagram, only this is related to the optical module

Thanks,

bin

HI Lucas，

During the test, it was found that it was normal for the same optical port to be repeatedly inserted and removed with a 1G optical module, but it was abnormal with a 10G optical module. Did this indicate that it had nothing to do with DS110DF111

Thanks，

bin

Hi Bin,

Thank you for answering my questions and sharing more details about the issue.

5. With default configuration, LOS/INT# output is driven low when a valid signal is present on channel A. Based on the connected network shown in the schematic, the LED should be on when a valid signal is detected, off when a signal is not detected. I'd like to understand the LED behavior through the duration of the test.

6. Please write 0xFF=0x04 or 0x0C before reading registers 0x02 and 0x54. The default value for both of these registers is 0x00, so it's possible your register reads are already correctly targeting channel A register set.

Can you read registers 0x02 and 0x54 at the following times? I'd like to understand how these statuses change through the duration of the test.

• Before beginning the test
• Read repeatedly while removing and inserting the module
• After the test is complete and link is down

Regarding 1G optical module test result: this result possibly suggests the issue may be tied to the 10G module and not the retimer. However it's difficult to say conclusively without more information. I'd like to understand retimer statuses during the test before I reach a conclusion.

Best,

Lucas

Hi Lucas,

Thank you for your advice. I will conduct the following test based on your advice

5. In the default configuration, the led behavior you said is reasonable in theory, but in reality, it seems that regardless of whether there is an effective signal detected, the led is bright. I will check the system driver setting problem again

6.When 0xFF=0x04, the value of 0x02 is 0xdc, and the value of 0x54 is 0x80, regardless of whether the link is up or down
Then I did a test of repeatedly plugging in and out the module, reading the values through the loop, and found that sometimes the value of 0x02 changed from 0xdc to 0x9c, and then back to 0xdc

Such a test result can know whether the timer is the problem? Looking forward to your reply

Thanks，

bin

HI Lucas，

I took a closer look at the schematic and found that INB+ and INB- these two pins are connected to the light slot of the light port, does this help? The retimer may be required to reset the optical port and link up the optical module again.

Thanks，

bin

Hi Bin,

Based on the LED behavior and register values, the retimer is consistently detecting a valid signal and locking to it through the duration of the test. The retimer will unmute its output when it obtains CDR lock, so the retimer doesn't appear to be preventing data transmission when link down occurs.

What conditions need to be met for the link to be declared up? Does the signal received by the optical module need to meet a certain eye mask or a certain BER measurement?

I don't quite understand what you mean by the "light slot of the light port." Can you share a system block diagram showing what the retimer is connected to on both sides? This may be helpful for me to understand what the full system looks like.

Best,

Lucas

Hi Lucas,

I'm sorry, my description may be wrong. I have uploaded a system block diagram, please check.

As you can see, INB+ and INB- are connected to CN2401(the green line in the figure). This is the insertion position of the optical module.

Do you mean to say that the behavior and register value of the LED is normal? Won't it affect the link?

The link does not need to meet other conditions. Only an optical module needs to be inserted.

In addition, I also carried out the following register reset operation, but it still does not work, please tell me what other methods?

Thanks，

bin

Hi Bin,

I understand, the SFP module is connected to INB/OUTA, not INA as I previously thought. The LED behavior and registers I asked you to check are related to data received on INA and therefore aren't applicable to the module insertion/removal issue.

Can you write 0xFF=0x05, then read registers 0x02 and 0x54 at the following times? This will select the channel B register set.

• Before beginning the test
• Read repeatedly while removing and inserting the module
• After the test is complete and link is down

Is the customer using any custom register configurations? I do not recommend calling a register reset as this will reset all register values back to default settings.

Best,

Lucas

Hi Lucas,

Select channel B for the test. The results are as follows.

• If the link is normal and the link is up, the value of register 0x02 is 0xdc and the value of register 0x54 is 0x80.

• When inserting and removing a module, the value of register 0x02 changes between 0x00 and 0x04, and the value of register 0x54 is always 0x80 (the link is still normal after the module is reinserted for the first three times).
After the module is inserted and removed for the fourth time, the link is found to be abnormal and link down. In this case, the value of register 0x02 remains 0xdc and the value of register 0x54 remains 0x80.

• If the link is down, the values of registers 0x02 and 0x54 are 0x00.

For DS110DF111, we have basically no custom register configuration for it, and many things are used by default.

Looking forward to your reply.

Thanks，

bin

Hi Bin,

Lucas is out of office for a couple days, so I can help support this until he returns.

I'd like to share some background on the registers that Lucas has been inquiring on.

Register 0x02

Register 0x02 has information on the CDR lock status of the device.  If bits 3 and 4 of register 2 are set, this indicates the device has CDR lock.  Your observation of 0xdc is very common to observe for CDR lock.  The table below is from the DS110DF111 programming guide.  A value of 0xDC shows that PPM count is met, auto adaptation is complete, the retimer has CDR lock, and single bit threshold is met.

Register 0x54

Bit 7 of register 0x54 indicates if the device detects a signal at the receiver.  We would expect the device to detect a signal when the module is present.  When the module is removed, we would not expect a signal to be detected.

Regarding your observations:

After the module is inserted and removed for the fourth time, the link is found to be abnormal and link down. In this case, the value of register 0x02 remains 0xdc and the value of register 0x54 remains 0x80.

-> It sounds like you're observing that the link is down while the retimer has CDR lock (Reg 0x02 = 0xDC).  If this is the case, it could suggest an issue with the retimer adaptation.

I have a couple experiments in mind.  For these experiments, if it's convenient, could you provide register dumps for retimer channel B?  If register dumps are inconvenient, please read back registers 0x02, 0x27, 0x28, 0x52, and 0x54.

Registers 0x27 and 0x28 have the retimer internal HEO/VEO measurement.  Register 0x52 reads back the retimer CTLE value that it adapted to.

1. For a normal link state (link is up), can you dump the channel registers?
2. For a link down state that occurs after unplugging and replugging the optical module, can you dump the channel registers?
   1. After dumping the channel registers, can you try performing a CDR reset?
      1. Set channel B register 0x0A = 0x1C.  This puts channel B into CDR reset state.
      2. Set channel B register 0x0A = 0x10.  This releases channel B from CDR reset state.
      3. Check link state to see if link is up.  Please also dump channel registers after performing CDR reset.

Thanks,

Drew

Hi,Drew

According to your suggestion, I conducted the following experiment.
1.In the case of a normal link state (link connected), the associated register values are as follows.
0x02 0xdc
0x27 0x1a
0x28 0x5c
0x52 0x00
0x54 0x80

2.If the link down state occurs after the optical module is removed and reinserted, the related register values are as follows.
0x02 0xdc
0x27 0x19
0x28 0x54
0x52 0x00
0x54 0x80

3.After the link down state appeared, I performed a CDR reset and then queried the register status again as follows.
0x02 0xdc
0x27 0x1a
0x28 0x58
0x52 0x00
0x54 0x80

4.Also, when I unplug the link, the value of 0x52 is 0xa5 and the other values are 0x00.

For registers 0x27 and 0x28, the values keep changing during the test. Does this matter? By the way, what does HEO/VEO mean?
In fact, the value of the retimer related register address I have tested myself, but also according to the document to try to write the value, but it seems to be useless.

Looking forward to your reply.

Thanks，

bin

Hi Bin,

Thanks for getting back to me on this with the register values.

bin lin said:

3.After the link down state appeared, I performed a CDR reset and then queried the register status again as follows.
0x02 0xdc
0x27 0x1a
0x28 0x58
0x52 0x00
0x54 0x80

After you performed the CDR reset, did the link come up, or did it remain down?

HEO and VEO stand for horizontal eye opening and vertical eye opening.  These are measured inside the retimer and are indicators of the signal quality.

Empirically, TI has observed that a HEO of 0.4UI and VEO of 200 mV or better yields good BER performance.  The results you reported indicate a HEO just shy of 0.4 UI and a VEO exceeding 200 mV.  Assuming you are observing good performance in a normal linkup state, I would not consider a HEO of 0.38 to be of immediate concern.

We also see that there is not a significant difference between link down HEO/VEO and link up HEO/VEO.  This would suggest that the retimer is receiving a good signal in both these cases.

On your host ASIC/CPU, do you have PRBS generator / checker capability?  It would be helpful to confirm if link down state can be correlated to BER.

Thanks,

Drew

Hi Drew，

3. When the link is down, the CDR is reset, but the link is still down.

Based on your analysis, can you conclude that link down is not related to retimer

I have a linux system, the cpu is NXP chip, I think there is no PRBS generator/checker function

Thanks，

bin

Hi Bin,

Based on the CDR lock status and internal HEO/VEO measurements of the retimer, there is no clear indication that the retimer is the root cause of the link down.

Does your CPU have any diagnostics information available? It will be necessary to check from the CPU if any eye mask or BER issue is occurring and causing the link down.

Best,

Lucas

Hi Lucas,

I looked at the cpu related information, found that it may be related to the system driver, repeatedly plug and unplug the port to disable, should not be related to retimer.

I will continue to check the driver here. Thank you for the help you gave me during this period of time to help me solve the problem.

Thanks，

bin