• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 3 answers
  • Subscribers 33 subscribers
  • Views 423 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TNETE2201B: SYNC issue

ttd
Mastermind 8120 points
Part Number: TNETE2201B

Dear Technical Support Team,

When specific data is received,  62.5MHz clock waveform supplied by RBC0 continues abnormally.

At this time, K28.5 is input regularly, however SYNC doesn't show High (SYNCEN is enable).

This issue is not always occurred(sometimes occurred).

When change LCKREFN such as high → low → high, a correct 62.5MHz clock was output and SYNC was also high.

So I guess that CDR doesn't lock during SYNC issue. 

■Received pattern for SYNC 

TNETE2201B is received following pattern continuously.

/K28.5/D21.5/D0.1/D0.0/ or K28.5/D2.2/D0.1/D0.0/

■Behavior about RBC0

When a problem occurred, it was confirmed that after outputting a normal 62.5MHz clock for 5 cycles, it was stretched once at the rising edge and once at the falling waveform. After that, this state is repeated

If differential input( K28.5) is nothing , the output clock of RBC0 shifts phase and TNETE2201B stretches the clock of RBC0 just once.
I think this is the correct device spec behavior( Figure 2. Word Realignment Timing Characteristics Waveforms on datasheet) for K28.5 character detection.

■Questions

①Is this RBC0 expected behavior(stretched clock twice)  as a device when SYNC hasn't been high and CDR hasn't been locked?

②Have you ever seen this SYNC and RBC0 issue?

③Please investigate the route cause of this event and confirm its ripple.

   For example , does it occur issue other than the Autonego code (/K28.5/D21.5/D0.1/D0.0/ or K28.5/D2.2/D0.1/D0.0/)  ?

Best Regards,

ttd

  • 0
    Mastermind 8120 points

    Dear Technical Support Team,

    Do you have any update so far？

    I think CDR doesn't lock following case generally.

    ・Noise on Power Supply

    ・refclk has some jitter.

    ・input serial data has some jitter

    Best Regards,

    ttd

  • 0 in reply to ttd
    TI__Guru* 93670 points

    Greetings,

    Given in your experiment LCKREFN was asserted and device was able to lock, this means we have reseted or restarted the PLL lock procedure. As noted in data sheet "receive PLL operation", arbitrary phase shift in the incoming data causes PLL attempt to lock. It seems power supply noise may cause PLL to drift thus special care should be taken with power supply filtering. 

    Regards,, Nasser

  • 0 in reply to Nasser Mohammadi
    Mastermind 8120 points

    Hi Nasser,

    Thank you for your reply.

    The PLL attempts to relock such as "receive PLL operation", but is it possible that the PLL could not lock within 2.4us(incoming data phase shift ) and 500us (power up scenario:  RC0 and RC1 = 2.2nF is my setting)?

    Also, if the power supply or input data is unstable during relock, does the above situation occur?

    ■Description of "receive PLL operation"

    If during normal operation a transient occurs, which is defined as any arbitrary phase shift in the incoming data and/or a frequency wander of up to 200 ppm, then the PLL recovers lock within 2.4 µs. Any condition exceeding these values is considered a power-up scenario and the PLL recovers lock within 500 µs with a 0.1 µF capacitor the PLL recovers lock within 10 ms on power up (see the following note).

    Best Regards,

    ttd

  • 0 in reply to ttd
    TI__Guru* 93670 points

    Greetings,

    If there is un-stability on the incoming data - phase shift or stretching - or if there is power supply noise then it may cause VCO control voltage to drift and thus cause failure to lock or lock with high bit error. It would be a good experiment to use clean lab supply first to make sure this issue is not contributed to the power supply noise. 

    Regards,, Nasser

  • 0 in reply to Nasser Mohammadi
    Mastermind 8120 points

    Hi Nasser,

    I understand that un-stability on incoming data and noise on power supply cause unlock of PLL.

    By the way, have you ever seen my RBC0 issue(stretched clock twice)?

    Maybe, local TI FAE  sent you the detail of document about this issue.

    Just  specific patterns as following doesn't look PLL sometimes. 

    /K28.5/D21.5/D0.1/D0.0/ or K28.5/D2.2/D0.1/D0.0/

    This device detect K28.5(-RD) as comma, so if K28.5(＋RD) is received, then skip detect comma(mean SYNC keeps LOW), right?

    ■comma character on expected boundary(Page 7)

    ---------------------------------------------------------------------------------

    The K28.5 character is defined in the fibre channel standard as a pattern consisting of 0011111010 (a negative number beginning disparity)

    with the 7 MSBs (0011111) referred to as the comma character. The K28.5 character was implemented specifically for aligning data words.

    ---------------------------------------------------------------------------------

    Regards,

    ttd

  • 0 in reply to ttd
    TI__Guru* 93670 points

    Greetings,

    I did see your earlier presentation showing RBC0 stretching twice due to idle character(K28.5). Given this has not been reported by other customers and K28.5 is very common in fiber channel, i am wondering if there is something specific about the data pattern that you are using. RBC0 is the divided recovered clock. One possibility is that perhaps incoming data rate could be on the margin. For example, can you please confirm incoming data rate is at 1.25Gbps+/-0.01% or within 100ppm?  I am wondering if this could be why we see RBC0 stretching under this condition causing VCO control voltage to drift. Then by applying LCKREFN it gets re-centered again.

    Regards, Nasser

  • 0 in reply to Nasser Mohammadi
    Mastermind 8120 points

    Hi Nasser,

    Thank you for your reply.

    I don't know why it doesn't LOCK.

    Since it occurs when / C / = / D0.1 / D0.0 / or / D0.1 / D0.2 /, is it possible to reproduce this event in TI Lab?

    It does not always fail as the probability of occurrence, and it returns with LCKREFN, so it seems that there is a dependency on the bit pattern that the CDR sometimes does not work well.

    ■Clock Deviation

    The deviation when the measuring instrument was connected to the opposite side was -3.3ppm, which was within the specified value.
    This measuring instrument can change clock with a deviation of ± 100ppm.
    As a trial, we confirmed at + 100ppm (100.7ppm in actual measurement) and -100ppm (-99.3ppm in actual measurement), then confirmed that the event was reproduced in all states including 0ppm.In addition, we have confirmed that multiple types of devices facing each other cause events, and we anticipate that the cause is low due to the deviation of the reception clock.

    ■Clean Power Supply

    We connected an external clean regulated power supply and conducted a reproduction test, but confirmed the reproduction of the event even in the state of external power supply.

    ■Supplemental Information

    I will share the detail of document through TI FAE.

    I don't know if it will be helpful, but I also measured the frequency of RBC0 when the event occurred.
    The measurement results are described in the attached file "Supplement 1".
    Considering the clock extension, the PLL seems to be pulling in the correct clock.
    Also, as described in "Supplement 2", the fact that stretching occurs when RBC0 is "H" is different from the waveform observed when the data sheet or differential is not input, and it may be a hint. thinking about.
    We apologize for the inconvenience, but we hope that you can refer to this point as well.

    Best Regards,

    ttd

  • 0 in reply to ttd
    TI__Guru* 93670 points

    Greetings,

    Thanks for sending me the presentation.

    Could you please let me know if you pulse SYNCEN pin, does this clear the stretched RBC clock?

    Regards,, Nasser