• State TI Thinks Resolved
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 99 subscribers
  • Views 106 views
  • Users 0 members are here
Support feedback
Options
Options
Related

TDA4VL-Q1: MCU_CLKOUT for Serdes

Daviel Almonte
Expert 3265 points
Part Number: TDA4VL-Q1

Tool/software:

hello! 

the datasheet specifies that the MUC_CLKOUT0 is meant for Ethernet Phys. if we use this cock as a Deserilizer's ref clock, would it affect the the RGMII communication? below is the clock scheme. 

  • 0
    TI__Guru 62120 points

    Daviel,

    Sorry for my late response during my OoO.

    I would not suggest to use the internal clock to be fanned out to be used for Eth PHYs as their clock performance may not meet the required RGMII spec. 

    I would recommend using an external clock source to communicate with the PHYs. 

  • 0 in reply to ShreyasRao
    TI__Expert 3240 points

    Hi Sheyras,

    What are the clock specifications from the TDA device? Below I have the clocking requirements:

    Thanks,

    Tom

  • 0 in reply to Tom Lynskey
    TI__Guru 62120 points

    Hi Tom,

    I will look into this internally and will let you know.

    Does the LMK device provide the freq tolerance and stability as desired by the PHYs and Serializer/ Deserializer? 

  • 0 in reply to ShreyasRao
    TI__Expert 3240 points

    Hi Shreyas,

    I will check back, let me know about the clocking.

    Thanks,

    TL

  • 0 in reply to Tom Lynskey
    TI__Guru 62120 points

    Hi Tom,

    None of the output clocks of the SoC are intended to be used as a low-jitter reference clock. I would think that there will be communication issues if using them as clock source. 

  • 0 in reply to ShreyasRao
    TI__Expert 3265 points

    Hi Shreyas,

    The Datasheet specifies that it is used for Ethernet Phys. is this a mistake in the datasheet?

  • 0 in reply to Daviel Almonte
    TI__Guru 62120 points

    Hi Daviel,

    The clock output can be used for the Ethernet PHYs, however, the performance of the clock must be validated by the customer to ensure that it meets their system requirements.

    There are too many variables that can impact jitter and hence we do not define the performance of our clocks in the datasheet.  One example is the combination of the device reference clock frequency and the PLL configuration required to achieve the desired frequency, where jitter can be significantly different if the PLL is configured to operate in integer mode vs fractional mode, or even different M/N values.  Another example is that the PLL power supply noise on the customer's PCB can impact jitter. 

    These system-level dependencies vary based on the specific implementation.  Therefore, we tell customers that they can use the clock output as long as they validate that its performance meets the requirements of the attached device(s).