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.

[FAQ] AM6442: MCU_OSC0 Crystal Circuit Requirements

Part Number: AM6442

Tool/software:

Dear Sitara HW champs,

 

In the Table “6-19. MCU_OSC0 Crystal Circuit Requirements” in the AM64x datasheet, it is specified the following :

. When not using the RGMII and/or RMII interfaces, then +/-100 ppm Xtal could be used

. When deriving the AM64x clock out to supply the ETH PHY, then  +/-50 ppm Xtal should be used

However, When using an external clock not derived from the AM64x clock for the ETH PHY (RGMII/RMII I/F), could the +/-100 ppm Xtal be used?

Thank you!

 

Best regards,

Guillaume

  • The same frequency accuracy requirements apply when using a crystal circuit or an LVCMOS clock source.

    Note: When selecting a clock source, the system design must consider temperature and aging characteristics of the source based on worst case environment and expected life expectancy of the system. In most cases you will need to select a clock source with an initial accuracy of about 30 PPM to provide margin for error introduced by temperature and aging.

    We are in the process of creating a new revision of the AM64x datasheet and it will include a new table that defines MCU_OSC0 LVCMOS Digital Clock Source Requirements. 

    Regards,
    Paul

  • Dear Paul,

    Thank you for taking the time to answer this question.

    The way you addressed it leads me to think that if we are using an RGMII and/or RMII interface, we should always stick to a +/-50ppm for validation. This criterium only changes (+/- 100 ppm) if we are not using an RGMII and/or RMII interface.

    However, the selection of the  clock source should be done towards +/-30ppm.

    Is that correct?

    Best,

    PS: Thank you for letting us know about an incomming revision of the AM64x datasheet including a new table for MCU_OSC0.

  • Yes. The 50 PPM requirement is a function of the RGMII and RMII standards. The AM64x device only requires an accuracy of 100 PPM when not using RGMII or RMII. The PLLs in AM64X will lock their output to the reference clock when producing a higher frequency clock for the various internal circuits. Therefore, the PLL outputs will have the same PPM error as the reference clock source.

    You may be able to find a clock source that has very small frequency variation due to temperature variations and aging.  If so, you may be able to select a clock source with a slightly higher initial accuracy. The combination of initial accuracy frequency error, temperature variation frequency error, and aging frequency error needs to be less than the respective PPM limit.

    FYI, I sent Guillaume an email with two snapshots of the draft datasheet content.

    Regards,
    Paul

  • Thank you very much for this clarification Paul, that helped me understanding the limitations.

    I wish you a good day.

    Best,

  • One last question: when you say "reference clock", do the PLLs in the AM64X in the case of the RGMII or RMII interfaces synchronize on RMII_REF_CLK? Or everything is done internally? Because if we provide an approriate 50ppm clock on this pin (RMII_REF_CLK), I wonder if we still have to ensure a +/-100 ppm on MCU_OSC0?

  • Yes. You still need to limit maximum frequency error to 50 PPM.

    Both clocks have the same requirement, where they need to operate within the +/-50PPM limit to ensure there is not too much difference in the rate which data is transmitted vs the rate the receiver is operating. If there is too much error the transmit rate from one end may over-run elastic buffers which were only designed to accommodate a maximum difference of 100PPM, which could occur if one end is operating 50PPM fast and the other end is operating 50PPM slow. The Ethernet standard had to draw the line somewhere and they decided to select the limit of +/-50PPM for RMII and RGMII. Note: The limit was +/-100PPM for the MII standard but was reduced to +/-50PPM when they defined the RMII and RGMII standards.

    The Ethernet data must be moved to/from the RGMII/RMII side of the Ethernet MAC to/from the other side of the Ethernet MAC that is communicating with other internal logic functions operating from a different clock domain. The elastic buffers that span across the clock domains were only design to accommodate the maximum frequency difference allowed by the Ethernet standard. Increasing the elastic buffer size to allow for a larger frequency difference than defined by the Ethernet standard would unnecessarily increase the elastic buffer size and increase silicon cost.

    Regards,
    Paul

  • Dear Paul,

    Thank you very much for your answer, everything is now crystal clear.

    Best,

  • Hello Valentin, 

    Thank you for the note.

    Regards,

    Sreenivasa