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.

TMDSCNCD28388D: internal or external clk distribution though ethernet/ethercat PHY

Part Number: TMDSCNCD28388D
Other Parts Discussed in Thread: DP83822IF, DP83822I, DP83822HF, DP83822H

Hi, Ive a doubt regarding clk distribution in controlBoard.

Control board uses an external clk and a clk driver to distribute clk to ethercat/ethernet PHY and uC.

The question is why to do these if the uC has the multiplexing capability to use crystal/external clk and output from gpio154

I've paste here the controlBoard implementation detail where it use a external clk and a driver with selection capabilities using jumpers and after that mine implementation with only one external clk directly coupled to uC and then PHY use pin gpio154.

Is mine approach correct? Should it be work ok? which is the criteria to choose one or the other?

thanks in advance and best regards.

Control Board CLK page

clk distribution on control board. one external clk plus clk driver


 

clk driver -> ethernet

the clk comes directly from driver and not from uC pin.


                                                                                                          

Mine approach, external clk IC to uC as the only main system CLK

gpio156 multiplexed as ethercat/ethernet clk -> ethernet PHY pin XI

 

 

gpio154 uC multiplexed as ethercat/ethernet clk (by firnware)

 

datasheet multiplexing detail on pin 154

  • Pablo,

    The controlCARD was setup to support both an external clock and the ECAT_PHY_CLK out feature of the device. There is no issue if you choose to use ECAT_PHY_CLK to provide a clock source to the etherCAT Phy.

    Regards,
    Cody 

  • Hi Cody, thanks for the quickly reply.

    I've added a resume of what is my intention to do to clarify the setup and to ask you again if it'll work. If my setup is incorrect I'll mess-up the whole board manufacture process and a lot of person will be angry....So I'd like to be pretty sure you understand me and my approach is correct. Thanks in advance again.

    There is my handwritten schematic. The former is the default controlBoard clk distribution and the last is my approach. What do you say/??

  • Pablo,

    A couple of comments here.

    1. ECAT_PHY_CLK works.
      1. This is intended for use with EtherCAT phys.
      2. This has not been specified to work with an Ethernet phy, it may have more phase shift or jitter more than that specification allows.
      3. F28388D is still in a device"Preview" state. While validation of the ECAT_PHY_CLK feature has happened, the full characterization of this feature is still on going.

    I would recommend that you use an external clock source until this feature has been fully validated(this will be completed when the device enters a "active" state on TI.com) Implementing something similar to the controlCARD could be a good option for you, after the device releases you could depopulate the 25Mhz clock and buffer source and use ECAT_PHY_CLK option if desired.


    Regards,
    Cody 

  • Hi Cody, gotcha. I'll take your suggestions for my first try board and I'll see then.

    But by the way, what do you think about the external xtal options for all of the PHY's IC like the datasheet recommends? I's completely legal and tested isn't it? or there has to be a clk sync between uC and PHY's IC reference clk... I guess not.

    From DP83822HF, DP83822IF, DP83822H, DP83822I datasheet

    Thanks! my best wished for the new year.

  • I'm slightly confused by your question, but you do not need to use the same clock source for the PHYs and the F28388D device.

    You can use a crystal for the F28388D device as long as it meets the PPM requirements for Ethernet and EtherCAT. If you wish to use the crystal for the PHYs i would recommend you to look at their Datasheets, as this can change from device to device.

    Regards,
    Cody 

  • Hi Coddy, let me try to clarify.

    More than a question is just to have a set of option for clk source and distribution for uC and PHY's in adition to the controlBoard schematic to decide when routing (next week). If I place uC away the PHY's or the PHY's away from each other it might not be a good idea to carry 25Mhz crossing all the board.

    1) controlBoard: 1 external clk for uC (20Mhz). 1 external clk (25Mhz) plus buffer distribution for ENET/ECAT PHY's

    2) apporach_2: 1 external oscilator for uC, and then uC gpio's to ENET/ECAT PHY's

    3) approach: 3 external oscilator for uC and a xtal for each ENET/ECAT PHY's

    4) approach_4: xtal for uC and xtal for each ENET/ECAT PHY's

    5) approach_5: internal OSC1/OSC2 for uC and xtal for each ENET/ECAT PHY's

    So what is your suggestion/opinion on those approaches 2 to 5? Do you think thouse will work?

    I may combine more than one approach on same board based on size constraints, for example external oscillator plus xtal, but I'd like to know that at least one will work fine.

    Thanks!

    Pablo

  • Pablo,

    internal oscillator does not meet the PPM requirements for EtherCAT or Ethernet, so that is not an option.

    I agree that it is not a good idea to route your clocking traces long distances. You will need to decide what is best for your system.

    Using a X-tal or a external oscillator should be fine for the C2000 device as long as it meets the PPM requirements. I cannot comment on what will work for the PHY's clock source, please look at the documentation that device.

    Regards,
    Cody 

  • Hi Cody, the internal oscillators approach should use xtal for the PHY's so thouse IC meet the requirements and the uC doesn't need an external clk. Maybe I'll try that plus a xtal for the uC too.

    But your answers are more than clear. I'll close the question now and reopen it if I found more doubts during the layout.

    Thanks you very much for your support

    Pablo.

  • Thanks. I'm glad I could help. 

    If the thread is closed when you have more questions, feel free to use the "ask a related question" button.

    Regards,
    Cody