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.

DS90UB914, a phenomenon under fierce noise

Dear Specialists,

My customer is considering DS90UB913 and DS90UB914.

He would like to know behavior of receiver PLL under noisy environment.

Could you please advise?

When the fierce noise is contaminated at either startbit or stopbit, how is the phenomenon of the device.

(1)Does it restart for PLL lock?

(2)Does it have a link error count function the same as DS90UB926?

I appreciate your great help.

Bestregards,
Shinichi

  • Hello,

    The noise margin constraints on 914A PLL is listed in our datasheet.

    1) When device unlocks it will subsequently try to re-obtain LOCK by default. Some registers will be reset including error count registers 0x1A and 0x1B. The specifics on the registers which are reset is in the datasheet.

    When the device receives errors it will not restart (unlock then re-lock) which is different from functionality on 92x devices. These errors on forward channel will be shown in registers 0x1A and 0x1B as mentioned above.

    2) No, link error function is different. When 914A receives errors on forward channel link, it will not lose LOCK. The 926 device will lose LOCK after a certain threshold of errors are reached. Taken from UB926 datasheet, page 42 for register 0x65:

    "Link Error Count Threshold: Counter is pixel clock based. clk0, clk1 and DCA are monitored for link errors, if error count is enabled, deserializer loose lock once error count reaches threshold. If disabled deserilizer loose lock with one error."

    By default, Link Error Count Enable is disabled.


    -Sean
  • Dear Sean

    Thank you for your reply.

    I understand operation of 914A is different from 926.

    I try to understand your advise well.

    If I have an additional question, I will send the message.

    I appreciate your great help. 

    Best regards,

    Shinichi