• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 32 subscribers
  • Views 111 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

DP83640: About DP83640，does the Synchronous Ethernet Mode mentioned in AN-1730 need running the PTP stack？

DP83640: Disabling Synchronous Ethernet Mode after synchronized to PTP master

mc b
Prodigy 145 points
Part Number: DP83640

Tool/software:

Hello , 

I have a few questions for DP83640's Synchronous Ethernet Mode.

1-) do we need to set anything other than SYNC_ENET_EN bit to become ptp slave for the Synchronous Ethernet Mode

2-) After we set SYNC_ENET_EN  bit , how can we know if the synchronization  is done ? I guess there should  be couple of messages exchanged between ptp master and ptp slave, how can we know if the initial synchronization is done ? 

3-) once we synchronized to the  PTP master , now we have synchronized ptp counter in  DP83640, but how can we synchronize a mcu timer counter to DP83640's ptp counter ? Do we need any int -gpio pin? or this can be done without using gpio or int pins?

4-) I want to set our device as PTP master once the current PTP master is gone , so my device is going to be transitioned from PTP slave to PTP master... if we clear the SYNC_ENET_EN   bit , since my ptp counters/timer already set to the  previous PTP Master , can i assume if the internal PTP counter value is still valid (assume there is 0 drift) , what i am trying to say clearing SYNC_ENET_EN  causes any counter or state reset ? 

5-) Once we clear the SYNC_ENET_EN bit , i assume we need to follow up the PTP protocol on the software , right ? 

 

  • 0
    TI__Mastermind 33225 points

    Hello,

    Please note that DP83640 is an older device and support is limited to existing documentation only.

    1) According to the SYNCE app note (SNLA100A), this should be sufficient.

    2) CLKOUT should be altered according to the figures within the app note.

    3) It would depend on what the MCU capabilities are which I cannot speak on. However, our CLKOUT should be able to be connected to a system if required.

    4) Sync will be lost if if the PTP master is gone unless the original signaling is captured elsewhere on the board (not available on PHY) as it is relying on the MDI. Would require extra logic on-board to account for this; HW or SW.

    5) See answer 4.

    Sincerely,

    Gerome

  • 0 in reply to Gerome Cacho
    Prodigy 145 points

    Hi Gerome,

    I appreciate your previous responses but would like further clarification on what happens under specific circumstances. I understand that synchronization requires ongoing communication with the PTP master, but here's what's currently unclear:

    Regarding to;

    2-) My question regarding the synchronization status was about determining when initial PTP synchronization has been achieved programmatically. It's not clear how monitoring CLKOUT would provide this information. Could you clarify or provide an alternative method to confirm that the device has successfully synchronized with the PTP master? clock out is just a squarewave signal , so how can i know if the current ptp counter value is valid or not yet by looking to the clock_out ? 

    4-) Upon assuming that the SYNC_ENET_EN bit is cleared after our DP83640 PHY has lost its PTP master, and assuming zero drift from the moment of synchronization loss and that we have a perfectly synced counter value at that point:

    1. How exactly is 'sync' defined to be lost in the absence of the PTP master signal? Is the PHY's PTP counter not capable of maintaining its value independently, assuming an ideal scenario with zero drift, even if just temporarily?

    2. Would the act of clearing the SYNC_ENET_EN bit inherently reset or otherwise disrupt the counter's stability or its maintained synchronized value?

    I am trying to understand whether there's a hardware-based reason for an instantaneous loss of synchronization when the master disappears and the SYNC_ENET_EN bit is cleared, notwithstanding the aspects of environmental drift over time which would naturally require a master to correct. Your input will greatly help me with the transition strategy from slave to master in the event of a master loss.

    Kind regards,

  • 0 in reply to mc b
    TI__Mastermind 33225 points

    Hello,

    Regarding Q2, I would imagine you would need to compare the CLKOUT post synchronization to the original master clock to understand if there has been a change due to the synchronization. 

    Regarding Q4, yes the clock should still be present after master is lost, but as you had mentioned drift would ultimately cause it to lose its original sync unless otherwise corrected. Regarding clearing the register bit, we do not have any knowledge of this as unfortunately support is limited strictly to datasheet and other existing documentation. 

    Sincerely,

    Gerome

  • 0 in reply to Gerome Cacho
    Prodigy 145 points

    Thank you for clarifications 

    "Regarding Q2, I would imagine you would need to compare the CLKOUT post synchronization to the original master clock to understand if there has been a change due to the synchronization. "

    We don't have ability to do that because ptp master a cisco swicth and has no any clock output. 

    there should be some mechanism in the DP83640 that tells us Synchronous Ethernet Mode locked or in sync 

    Since support is limited for DP83640 , is there any new equivalent product for this phy ? any new product with hw timestamp support . 

    Thank you again.

  • 0 in reply to mc b
    TI__Mastermind 33225 points

    Hello,

    There are no current standard ethernet products which have this feature. However, our DP83TG721 might be of interest.

    Most of our current portfolio from standard Ethernet side only does SFD for IEEE802.3. For SyncE, this has been left more as an application implementation where most of our modern portfolio does support adjusting their CLKOUT to the transmit clock, thereby allowing for SyncE with HW workarounds in the application.

    Sincerely,

    Gerome