DS280DF810: EOM monitor issue

Part Number: DS280DF810

Hi team

Our development product use DS280DF810  for Ethernet Switch. DS280DF810 is place between optical transceiver and SWLSI for 25G transmission.

We have questions about EOM monitor of DS280DF810.

When our development product is repeatedly powered on and off, the EOM monitor value may occasionally become 0 (channel register address 27, address 28).

No matter how many times  we read the address, the value remains 0.

At that time, a communication error or link down occur.

However, if we reset the CDR, the EOM monitor value will return to its original value and operation will return to normal.

Is this a bug?   missing some register settings?

One more thing,

In case of normal operation of DS280DF810, we repeatedly reading address 27 and address 28 to update the EOM monitor value,

but it doesn't seem to be updated. Please tell us how to update the value.

Best Regards,

K.Mizobuchi

  • Hi Mizobuchi-san,

    Regarding the EOM Reading 0 Issue:

    Given that EOM monitor is 0 and that a communication error or link down occurs, this seems to suggest that the retimer is not getting CDR lock.  Have you checked the CDR lock status in this condition?  Would it be possible to share a register dump in this state where 0x27/28 read 0 and also your device configuration sequence?

    Regarding the EOM Update Issue:

    How frequently are you reading 0x27/0x28?

    There is an option to force an EOM update.  Could you try writing the sequence below?

    ch_reg_0x23[7] = 1; // Enable override for HEO/VEO trigger

    ch_reg_0x24[1] = 1; // Trigger HEO/VEO measurement

    Thanks,

    Drew

  • Hi Drew-san

    Thank you for your reply.

    We will check your advice.

    Thanks,

    K. Mizobuchi

  • Hi Drew-san

    Have you checked the CDR lock status in this condition?

    =>Yes,  In case of  link down state, register values are 0x27=00, 0x28=00, 0x29=00,  0x78=30. 

    Would it be possible to share a register dump in this state where 0x27/28 read 0 and also your device configuration sequence?

    => What registers do you want to check ?

    => your device configuration sequence is below,

    //Disable CAL_CLK_Out
    debug i2c write 0 0x19 0xff 0x00
    debug i2c write 0 0x19 0x0a 0x01

    //setting channel Reg.
    debug i2c write 0 0x19 0xfc 0x01
    debug i2c write 0 0x19 0xff 0x03
    debug i2c write 0 0x19 0x00 0x04
    debug i2c write 0 0x19 0x0a 0x0c
    debug i2c write 0 0x19 0x2f 0x50
    debug i2c write 0 0x19 0x3d 0x0a

    //disable HEO/VEO
    debug i2c write 0 0x19 0x67 0x00

    //ch 6/4/2/0 open CDR
    debug i2c write 0 0x19 0xff 0x01
    debug i2c write 0 0x19 0xfc 0x55
    debug i2c write 0 0x19 0x0a 0x00

    //CH 7/5/3/1 power down driver,disable SD, PFD, CDR
    debug i2c write 0 0x19 0xff 0x01
    debug i2c write 0 0x19 0xfc 0xaa
    debug i2c write 0 0x19 0x15 0x18
    debug i2c write 0 0x19 0x1e 0xec
    debug i2c write 0 0x19 0x14 0x44
    debug i2c write 0 0x19 0x13 0xf0

    How frequently are you reading 0x27/0x28?

    => It is manual reading, so every few seconds.

    There is an option to force an EOM update.  Could you try writing the sequence below?

    ch_reg_0x23[7] = 1; // Enable override for HEO/VEO trigger

    ch_reg_0x24[1] = 1; // Trigger HEO/VEO measurement

    => Is "ch_reg_0x24[1]= 1 " read register ?

    =>We could not update EOM monitor by above sequence.

    Best Regards,

    K.Mizobuchi

  • Hi Mizobuchi-san,

    Thanks for sharing your configuration.  Could you share some background on why you're disabling the HEO/VEO lock monitoring?  I believe this is contributing to you reading back a HEO/VEO of 0.

    I was able to reproduce some similar behavior on the bench, but with the HEO/VEO lock monitoring disabled, I wasn't able to identify a manual override.

    Is "ch_reg_0x24[1]= 1 " read register ?

    It is documented as a read register, but the description for it seemed to suggest that it would be used to trigger a HEO/VEO measurement.  Based on this, I was wondering if the "read" description might be an error.  However, I tried testing this sequence in lab today and also found that it did not update EOM monitor.

    Thanks,

    Drew

  • Hi Drew-san

    Could you share some background on why you're disabling the HEO/VEO lock monitoring?

    => We thought this was an unnecessary feature when making it into a product.

    And this is because we want to reduce power consumption as much as possible.

    Even if HEO/VEO lock monitoring is disabled, we can usually see EOM monitor only once. But can not be updated.

    I believe this is contributing to you reading back a HEO/VEO of 0.

    =>We changed HEO/VEO lock monitoring to be enabled, but we found that it did not update EOM monitor.

    Can you see the EOM monitor updated in your lab ? If so, could you tell us the sequence ?

    And  are there any problem if EOM monitor is disabled ?

    Thanks,

    K. Mizobuchi

  • Hi Mizobuchi-san,

    =>We changed HEO/VEO lock monitoring to be enabled, but we found that it did not update EOM monitor.

    I see the EOM monitor update in lab when HEO/VEO lock monitoring is disabled.

    However, in the case where HEO/VEO lock monitoring was disabled and registers 0x27/28 read back 0, re-enabling the HEO/VEO lock monitoring does not resolve the issue.

     

    When you are testing with HEO/VEO lock monitoring enabled, are you just getting a single value and then find that it does not change?  How much do you expect it to change?  Are you changing the input signal to the retimer?

    And  are there any problem if EOM monitor is disabled ?

    The HEO/VEO lock monitor is used to see if the retimer should re-adapt to the input signal (in the event that input signal quality changes).  I wouldn't expect any issues with disabling the EOM monitor if the input signal quality is expected to be constant.

    Thanks,

    Drew

  • Hi Drew-san

    I see the EOM monitor update in lab when HEO/VEO lock monitoring is disabled.

    =>We understood that basically, EOM monitor disabled and EOM monitor update are not related.

    When you are testing with HEO/VEO lock monitoring enabled, are you just getting a single value and then find that it does not change?  How much do you expect it to change?  Are you changing the input signal to the retimer?

    =>Yes, The value was not updated whether we changed the input signal level to the retimer or not.

    We will consider it again.

    Thanks,

    K.Mizobuchi

  • Hi Drew-san

    We tried to test again. As the results,

    when HEO/VEO lock monitoring is enabled, we confirmed that EOM monitor can update by changing input signal level.

    when HEO/VEO lock monitoring is disabled, we confirmed that EOM monitor can not update by changing input signal level.

    We have questions below,

    What is the resolution of the EOM monitor?

    Where is the EOM monitor placed in the circuit block?

    Is it possible for the EOM monitor to become 0 if the input amplitude to the retimer is small not 0 ?

    Thanks,

    K. Mizobuchi

  • HI Mizobuchi-san,

    when HEO/VEO lock monitoring is enabled, we confirmed that EOM monitor can update by changing input signal level.

    when HEO/VEO lock monitoring is disabled, we confirmed that EOM monitor can not update by changing input signal level.

    I think these results make sense.  The HEO/VEO lock monitoring is responsible for automatically updating the EOM monitor.

    What is the resolution of the EOM monitor?

    The LSBs of the EOM monitor are 3.125 mV and 1/32 UI.

    Where is the EOM monitor placed in the circuit block?

    Please see where the eye monitor is placed in the block diagram below.  There is an error in the DS280DF810 block diagram showing two "PRBS Gen" blocks instead of one "PRBS Gen" and one "Eye Monitor" block.

    Is it possible for the EOM monitor to become 0 if the input amplitude to the retimer is small not 0 ?

    This is not something I have observed before.  We observe that if the retimer has CDR lock, it will have a non-zero eye.

    The procedure I found to reproduce a EOM value of 0 was to disable the HEO/VEO lock monitoring, and then physically connect a signal to the receiver of DS280DF810.  Since I was physically connecting SMA cables, this resulted in the retimer first receiving a single ended signal, then differential signal.  I believe this abnormal case lead to registers 0x27/0x28 reading back 0.

    Thanks,

    Drew