This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Tool/software:
Hi, ti team
For DS110DF111, it is followed by a 10G SFP optical module, but after repeated insertion and removal, the optical module cannot be used, and the link status is displayed down. Is this related to DS110DF111? How can it be solved
Thanks
bin
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.
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.
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.
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.
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.
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.
Condition | Reg 0x27 | Reg 0x28 | HEO | VEO |
Normal link state | 0x1a | 0x5c | 0.38806 | 287.5 |
Link down | 0x19 | 0x54 | 0.373134 | 262.5 |
After CDR reset | 0x1a | 0x58 | 0.38806 | 275 |
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
Hi Bin,
I understand, feel free to open a new E2E thread if you need additional support with the retimer.
Best,
Lucas