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.

DS90UB925Q Des - Input Eye Opening / Input Jitter

Hello,

It seems like the specification sheets for DS90UB925Q FPDLink-III Des does not precise what jitter is tolerated on input.

Could someone provide me this value please ?

Anymore, from my point of view, there is a mysticism with CML Output Monitoring Eye opening which is specified 0,4.UI typical (0,3.UI min). In addition it is written in DS90UB926Q's datasheet:

What should it be understood?Is input jitter tolerated the same as CML Output Monitoring jitter?

Really thanks in advance

Best regards,

Julien A.

  • Hello there,

    Is nobody want to answer my question?

    Best regards,

    Julien A.

    Julien Appaix said:

    Hello,

    It seems like the specification sheets for DS90UB925Q FPDLink-III Des does not precise what jitter is tolerated on input.

    Could someone provide me this value please ?

    Anymore, from my point of view, there is a mysticism with CML Output Monitoring Eye opening which is specified 0,4.UI typical (0,3.UI min). In addition it is written in DS90UB926Q's datasheet:

    What should it be understood?Is input jitter tolerated the same as CML Output Monitoring jitter?

    Really thanks in advance

    Best regards,

    Julien A.

  • Hi Julien,

    I apologize for the delay. The input jitter tolerance is shown in the AC characteristics section of the DS90UB925 datasheet.

    0.4 UI of jitter is the guaranteed minimum that we will tolerate. Less is obviously better, and under typical circumstances we can tolerate more (0.6 UI typical). 

    This is just the spec to make sure that the 925 will be able to lock to the PCLK signal. It doesn't necessarily mean that the 926 will be able to lock to the 925, since that takes into account cables, connectors, PCB layout, environment, etc. That's why measuring the 926 CML output is the best way to make sure that the system is robust.

    Let me know if there are any questions. Thanks,

    Jason

  • Hi Jason,

    Thanks for responding.

    I have realized I made a mistake... and I apologize for this.

    In fact, I am wondering about DS90UB926Q Deserializer input eye opening width minimal. What is this value in order the 926Q Deserializer is able to lock to the 925Q Serializer ?

    Julien

  • Hi Julien,

    If you probe at the FPD3 input to the 926, you won't see an eye because the high-speed forward channel data and low-speed back channel data are superimposed on top of each other. 

    The CML output pins, when enabled, show the recovered serial data, minus the low-speed back channel data. This is where we recommend measuring the eye opening. To enable the CML output, write 0x56 = 0x00. 

    Here are the eye opening specs from the 926 datasheet:

    Let me know if you need anything else.

    Thanks,
    Jason

  • Hi Jason,

    OK I have understood the reason why probing FPDLink-III channel at CML output.

    However in the context of a jitter budgeting, I am wondering whether the input eye opening minimal tolerated at the input of 926Q (or its input jitter maxiaml) is the same as CML output specs. I would like to know this in order to establish a RSKM (receiver skew margin).

    Thanks,

    Julien

  • Hi Julien,

    The input jitter can't be measured at the FPD3 input. To determine how much margin you have, measure at the CML loop-through output and compare to the eye height / width in the datasheet.

    Thanks,
    Jason

  • Hello Jason,

    Thanks for responding, thus I will take CML output width as the FPD3 input jitter tolerance maximal for my RSKM budget.

    Another question for you Jason:

    I understand perfectly well that I should/must use the CML ouput however could it be possible to probe the high-speed data forward channel directly at the receiver input by mean of an external filter? For example, using an external high-pass filter, could we remove the low-frequency back channel?

    Thanks,

    Julien A.