DS125DF1610: DS125DF1610

Hi Manar,

Can you provide us some information about what registers you are writing to get your feedback of HEO and VEO measurements? I suspect what may be happening is that there is another process running that refreshes the HEO and VEO measurement, and your program may be catching the HEO and VEO buffer at the moment it is refreshing, thereby producing a "0" readout.

If you could let us know your register write (or code) and corresponding read-back, this would be helpful for us to see what may be going on.

Thanks,

Michael

Hi Michael,

I am doing the reads from channel registers :
0x27 Horizontal Eye Opening
0x28 Vertical Eye Opening

My code is the only one running on the system and it's not multi-threaded , so I don't think it a contention on register read and write.

High level description :
My system is doing 4 data bits transmission on a cable and reading these bits on the other side of the cable.

I have DS125DF1610 device configured as Code generator running @ 10 GHz and generating PRBS patterns (4 data bits represented by 8 differential signals ) these bits are going to my transmitter which is send them on a cable.
One the other side I have a receiver module that is reading the data and the Rx output signals is connected to another DS125DF1610 which perform the eye check.

DS125DF1610 (Code Generator) --> Tx -- --Cable -- -- Rx-->DS125DF1610 (Eye Checker)

In the Eye Checker in some reads I get absolute zero on HEO & VEO , while all the other reads I got great eye opening reading. Meaning that either I get excellent eye opening or absolute zero (no poor signal readings !!)

Hi Manar,

Thanks for the description. I presume during this entire process that the DS125DF1610 you are using as an Eye Checker never falls out of lock?

If so, it appears that the issue is not a link-integrity one, but may be within the DS125DF1610 logic.

The HEO and VEO values are updated approximately every 10 ms, so my thought is that every so once in a while, you are catching the HEO and VEO at a point where it is refreshing the value based on the next measurement.

Please try the following to force a manual trigger for the HEO/VEO readback. Assuming you are in the channel register page:

Reg 0x67[5] = 0 //Disable HEO/VEO EOM Lock Monitoring
Reg 0x23[7] = 1 //Acquire HEO/VEO when Reg 0x24[1] = 1
Reg 0x24[1] = 1 //Get HEO/VEO Measurement (self-clearing)

--- Readback Reg 0x24[1] and wait until it becomes 0'b, indicating that HEO/VEO measurements are ready
Read Reg 0x27 for HEO
Read Reg 0x28 for VEO

Reg 0x67[5] = 1 //Re-enable HEO/VEO EOM Lock Monitoring
Reg 0x23[7] = 0 //Set HEO/VEO acquisition back to normal operation

Regards,

Michael

I am not sure that I understand your answer, l have couple of question about it:
1) can you elaborate about the refresh rate of 10 ms, do you mean that 10 ms is the maximum sampling rate.
So when I am transimitting at 10 GHz , the sampling is periodacly each 10 ms and doesn’t do eye check for each transaction?

2) The procedure that you describe above for manual locking , Do I need to perform it each sample , or it’s one time commands for init

Hi Manar,

1. The DS125DF1610 is constantly refreshing it's HEO or VEO readback value so that it ensures the "eye health" is good enough to maintain lock. This refresh rate is the default sampling rate that the HEO/VEO parameter is updated.

I am not quite sure what you define as "each transaction." Are you referring to each bit, or a string of bits? The HEO/VEO readback assumes many bits have gone by rather than a single bit transition before taking a HEO/VEO measurement

2. I recommend that the procedure described above be performed each time your program measures the incoming HEO and VEO so that after you obtain the measurement, the device resumes its automatic refresh behavior. Otherwise, if you simply just read back from Reg 0x27 and Reg 0x28, you can simply discard readback values of 0 HEO and 0 VEO under the assumption that you are only reading it once in a while and are not seeing this readback value repeatedly (thinking of this as a "noise filter" approach).

Hope this helps!

Regards,

Michael

Hi Michael,

Iam still confused :(

What do you mean refreshing HEO & VEO each 10 ms ? Does it mean that if iam reading the VEO & HEO each 1ms , I will get same reading 10 times till the next refresh ?

The intend of my setup is to validate the quality of my Tx & Rx over time, meaning that I am sending streams of bits over long period and analyze the eye opening, so adding this procedure will have overhead on runtime.

Hi Manar,

Your understanding is correct. The HEO and VEO value should be the same within approximately a 10 ms window, assuming that you start reading back immediately after the HEO/VEO value is refreshed.

The stored value in HEO/VEO is reset each time the lock monitor timing interval is reached and a new HEO/VEO measurement automatically begins. Therefore, to ensure your HEO/VEO readback is accurate, this automatic 10 ms "refresh" should be disabled by setting Reg 0x69[5] = 0. This way, your readback after writing Reg 0x23[7] = 1 and Reg 0x24[1] = 1 will be the most recently obtained HEO/VEO value. Otherwise, you risk the possibility of reading back the HEO/VEO value when a new automatic HEO/VEO measurement occurs.

Given that the HEO/VEO refreshes every 10 ms under normal operation conditions, will adding this procedure still cut significantly into your runtime?

Regards,

Michael

This intersiting , based on these fact I don’t need to do sample rate faster than 10ms.
I will update my test code to do sampling as you suggested based on the feedback and not periodically.
I can do all the calculations in the time interval of the 10 ms so there won’t be overhead for the procedure.

One more thing you mentioned the possibility of the eye checker getting out of lock, how can I check the status of the eye checker and make sure it’s still locked?

Hi Manar,

A quick way to do this is to read back Reg 0x78[4], which is the CDR lock status bit. This will tell you if the DS125DF1610 is currently locked or not. If you wish in your program to set an interrupt flag if the DS125DF1610 ever goes out of lock (in other words, an event flag), you can set the interrupt in Reg 0x79[1] and Reg 0x78[3].

I neglected to say that there is a Programming Guide available for this device that may assist with your coding development efforts. I will send an e-mail to you shortly with this document attached.

Thanks,

Michael

Hi Michael,

Is there any constrains on Reg 0x23[7] (EOM_GET_HEO_VEO_OV) ?

I implemented your suggestion in my code for manual triggering but I am not able to modify register EOM_GET_HEO_VEO_OV value to '1' , I am getting reading of 0 even after writing to it 1.

 

Please ignore my last post - I was able to write to register.

After I implement your suggestion to move from automatic to manual triggered reading of HEO/VEO, I am getting zero HEO & VEO.
Once in a while I get all lanes Eye opening is absolute zero while all other readings have excellent eye opening (as before with the automatic readings).

Any other ideas ?

Hi Manar,

Are you seeing zeros for all reads of HEO and VEO? If not, is the readback of zeros worse than before with automatic triggering?

Also, can you send information about the code you are writing? Perhaps we can try to emulate this behavior when we return from Thanksgiving holiday.

Please note that our team will be out until Monday of next week (11/27).

Regards,

Michael

it's the same switch automatic triggering

To give you the full picture :
I added a check for the CDR_LOCK_STATUS of the Eye Checker and found it @ unlock state when I am reading zero eye opening.

What can be the root cause for unlocked CDR ?
If the receiver stopped getting new data does it CDR goes out of lock ? or it's something related to it's internal clocking ?

Hi Michael,

After lot of debug I fount that in some of the runs the CDR is unlocked in the end of the initialization process, which caused to zero eye opening reads.

In my code I have a part of initialization in which I reset the CDR (using CDR_RESET_OV &  CDR_RESET_SM) , wait for 0.2sec then start the eye opening checking, in most of my regressions this code works as expected (I get CDR locked), while in some cases I am not getting CDR locked after reset.

Is it a deterministic operation ? meaning I can rely on waiting for enough period after reset then start the eye opening checking, if yes what is the recommended wait time ?

if no, what is the right approach to start eye opening checking after the reset.

  

Hi Michael,

I to solve the CDR unlock issue by increasing the wait time and to do restart but both didn't help, thus I am suspecting that CDR unlock is the symptom and not the issue.

I will try to enable the data lost interrupt and check if there is a situation where the Eye Checker stopped receiving any data, What do you think ?

If you remember in my system I have a retimer that is configured as pattern generator (PRBS31) and a receiver retimer in the other side of the cable configured as Eye Checker (which have the CDR unlock issue), Is there a way to validate that pattern generator is sending data after I configured it (by reading registers or  through interrupts) ?

*This check will help me to root cause the source of the problem of the unocked CDR.

To remind you , my system is as follow :   

Retimer (Pattern Generator - PRBS)  -> Transmitter >----------- Cable --------------> Receiver-> Retimer (Eye Checker - where I checked the CDR and got it unlocked in some of the runs in my regressions)   

Hi Manar,

My apologies for not following up from your most recent post. What was the root cause and solution?

Michael

The issue was related to trying measuring Eye Opening immediately after CDR reset, adding wait time of 2ms (probably less wait time will work , but to be on the safe side I used 2ms) after CDR reset achieved the locked and was able to read correct Eye Opening values.