DS125DF111: Manually setting DFE Tap

Hi,

Can you include details about how you are configuring the retimer? If using the GUI, you could save your configuration and share it so that I can review it.

Thanks,

Drew

Attached are a few different files. The first is from a successful boot and link with default settings. The other 2 are my attempts to manually set DFE Tap 1 to +4. The one titled DFE_POST_BOOT_080422 is what I see after booting from an EEPROM image that manually sets DFE Tap 1. These files are only from one of the CDRs in my link and as I explained I have 2 (one on each end of a coax cable) in my system. It seems that when booting from the EEPROM after manually setting the DFE Tap that I do not get a successful lock between both CDRs and what I have to do to resolve this issue is connect the GUI and then go to the high level tab, device status, and allow that to update and then the system will lock. It's like the system is getting hung or not automatically updating the HEO/VEO values after booting from the EEPROM image with manual DFE settings but once I use the GUI device status page to update those, it works. I have also tried to manually get things going after a failed boot by just using the lower level page of the GUI but I haven't had any success with that method. I suppose there is a process I would need to follow to manually get things up with that method that the 'device status page' is automatically doing. I also tried to upload the .hex files I am using in the EEPROM but this format would not allow me to do so. 

Working_080422.cfgManual DFE_080422.cfgmanual_DFE_post_boot_080422.cfg

Hi Joe,

Thanks for attaching the configuration files.  I'm looking into this, let's follow up on this in our call tomorrow.

Thanks,

Drew

Hi Joe,

I have a couple follow up ideas.

• We found that when we set ch_reg_0x24[1:0], this allowed for CDR lock.  Would it be possible to check and see if setting just one of those bits would allow for CDR lock?
• If you clear channel register 0x23[7], does this allow CDR lock to happen?  If it doesn't happen immediately, does it happen at all if you reset/release CDR?
• Could you try the attached hex file and let me know if there are any changes in behavior related to CDR lock?

Thanks,

Drewhttps://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/138/Mode2_5F00_Modified.hex

Drew,

     After trying this file I am still seeing the issue in my system. I have tried to disable all automatic adaptation by setting the mode to 0 and disabling the HEO/VEO lock monitoring but even then I still see this issue. Do you have any other suggestions for what I can do to ensure the CDR is not re-adapting or re-syncing during operation. 

Hi Joe,

I have a couple clarifying questions to make sure I'm understanding this correctly.  Are you seeing the issue where after the system soaks at high temperature, it goes out of lock for a small period of time and then relocks?  If I remember correctly, this didn't happen when manually setting the DFE taps with the "bad" hex file where you had to use the GUI to initiate CDR lock.  Now that you have the hex file that resolves the CDR lock issue with manual DFE taps, the system has the CDR lock glitch at temperature?

Joe_B said:

disabling the HEO/VEO lock monitoring but even then I still see this issue

Was this done by clearing 0x3E[7]?

Thanks,

Drew

Drew, 

     I see this issue after the system soaks at hot but only if it was soaked and cold booted at an extreme cold temp first. Yes, it appears to lose lock. Not sure how I can confirm this but that is what the behavior suggest as I get a short burst of lost packets on my test station. I was able to correct this behavior by manually setting the DFE taps via the GUI. However, I wonder that maybe what actually happened when I manually set the taps via the GUI was disrupt the CDR state machine. Similar to the disruption we saw with the state machine not automatically starting with the hex file I had created. I disabled HEO/VEO lock through register 0x3E[7].

Hi Joe,

Joe_B said:

I was able to correct this behavior by manually setting the DFE taps via the GUI. However, I wonder that maybe what actually happened when I manually set the taps via the GUI was disrupt the CDR state machine.

Would you do this configuration while the device was soaked at cold and then leave the GUI untouched through the remainder of your testing?  Trying to understand if this is related to GUI disruption of CDR state machine, or related to a particular register set by the GUI.

Thanks,
Drew

Drew,

     I can try this again tomorrow morning. I have another test running currently. I don't know that I can leave the GUI untouched since I need to swap between 8 CDR chips in order to set the DFE taps manually through the GUI. I will repeat what I did previously though and document the steps to share with you. 

Hi Joe,

Thanks for looking into this.

I think you have probably already verified that the data being sent to the retimer does not change over your temperature testing.  Would you be able to share some of the debug steps you have done through in this regard?  I'm going to check in with some colleagues regarding this issue and I'm sure they'll ask me if we know that the input data does not change.

Thanks,

Drew

Hi Joe,

Another follow up question:

Do you happen to know the board or device temperature while sweeping temperature?  Didn't know if there's any chance that there's a significant temperature difference between the temperature you soak at vs board temp.

Thanks,
Drew