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.

DP83867E: What is the propagation delay time for the DP83867E SGMII EVM back-to-back connection?

Part Number: DP83867E
Other Parts Discussed in Thread: DP83640

Thank you for your help.

DP83867E I am using two SGMII EVMs for back-to-back connection. There are no problems with basic operation of both 1000BASE-T and 100BASE-TX.
Currently, we are thinking of applying this to industrial Ethernet such as EtherCAT and CC-LinkIE TSN.
These industrial Ethernet devices can synchronize network-connected devices with high accuracy of less than 1 us. We have also confirmed that synchronization can be achieved using normal network wiring.
Here, I inserted a Back-to-Back connection test device using two DP83867E SGMII EVMs.
It has been confirmed that synchronization is possible with EtherCAT and CC-LinkIE TSN, but it has not been possible to ensure the standard accuracy of 1 us or less. I think this is probably due to the propagation delay of DP83867E. At this rate, we will not be able to meet the requirements of the standards, so we will not be able to achieve our goals.
As a method to solve this, for example, in CC-LinkIE TSN based on TSN technology, we think it may be necessary to take a method such as compensating for propagation delay with the transparent clock function of TSN, but TI's product Could you please suggest a way to solve this problem?


Thank you.

  • Hi,

    You mentioned it has not been possible to achieve 1us accuracy or less. What level of accuracy are you seeing?

    Please see the following latencies for SGMII to MDI on the DP83867. Can you compensate for this delay? 

    Note, we recommend using the DP83826 for 100Mbps EtherCAT designs. Please see the following app note: SNLA344B

    Thanks,

    David

  • Hello.

    Thank you for your reply.

    We are considering specialized repeater equipment such as the DP83867E SGMII EVM back-to-back configuration.

    For the back-to-back connection section, we want to use an interface that reduces the number of connection signal lines as much as possible, like SGMII.

    We would like to support industrial 1000BASE-T(CC-LinkIE TSN) and 100BASE-TX(EtherCAT) Ethernet.

    DP83826 can only support up to 100BASE-TX, but if it is limited to 100BASE-TX, will it have less delay than DP83867E?

    DP83867E SGMII EVM Back-to-Back Connection (Back-to-Back Connection with Coaxial Cable)

    (1) If DP83867E SGMII EVM Back-to-Back is not inserted

    This is the result of connecting two EtherCAT slaves under the EtherCAT master as an EtherCAT network configuration, and measuring the synchronous SYNC0 timing of slave No. 1 and the synchronous SYNC0 timing of slave No. 2.

    This is a waveform that measured the synchronous SYNC0 timing of slave No.2 (CH.4, green) using the synchronous SYNC0 timing of slave No.1 (CH.3, magenta color) as a trigger.

    The synchronization accuracy is within 1 us according to the EtherCAT standard.

    The synchronous SYNC0 timing of slave No.1 varies within -280ns/+360ns with respect to the synchronous SYNC0 timing of slave No.1.

    (2) When inserting DP83867E SGMII EVM Back-to-Back

    This is the result of connecting two EtherCAT slaves under the EtherCAT master as an EtherCAT network configuration, and measuring the synchronous SYNC0 timing of slave No. 1 and the synchronous SYNC0 timing of slave No. 2.

    This is a waveform obtained by measuring the synchronous SYNC0 timing of slave No.2 (CH.4, green) using the synchronous SYNC0 timing of slave No.1 (CH.2, light blue) as a trigger.

    is FastAcquisition mode measurement, ② is FastAcquitition + overwrite mode measurement.

    The synchronization accuracy is not within 1 us according to the EtherCAT standard.

    The synchronous SYNC0 timing of slave No.1 varies within -280ns/+1700ns with respect to the synchronous SYNC0 timing of slave No.1.

    Thank you.

  • Hi

    Thank you for sharing the plots.

    The DP83826 would offer slightly lower and more deterministic latency numbers, using the MII interface. From the Beckhoff PHY selection guide: "due to the higher latency of Gigabit Ethernet PHYs, it is recommended to use 100 Mbit/s Ethernet PHYs."

    Thanks,

    David

  • Dear David,

    Thank you for confirming.

    For 100BASE-TX (EtherCAT compatible), DP83826 is recommended because of its low propagation delay.
    Regarding 1000BASE-T (CC-LinkIE TSN compatible), we are still verifying it here, but it is unclear whether it will be able to meet the standard specification of synchronization accuracy of 1 us or less. Do you know of any achievements with DP83867E in 1000BASE-T industrial application cases (TSN base)?

    Thank you.

  • Hello,

    I work on the same team as David. Please expect a response by early next week.

    Sincerely,

    Gerome

  • Dear Gerom,

    Thank you for reply.
    We are waiting for you,

    Thank you very much.

  • Hello,

    Thank you for your reply.

    Sincerely,

    Gerome

  • Hello.

    The other day, I was told that DP83826 has less propagation delay for 100BASE-TX (EtherCAT compatible). thank you.

    While we are checking the track record of 1000BASE-T (TSN compatible), we would like to provide a little information about what we would like to see in our consideration.

    We are currently considering special repeater equipment that can support various types of industrial Ethernet such as 100BASE-TX (EtherCAT, PROFINET, EtherNet/IP, ModbusTCP, POWERLINK, etc.) and 1000BASE-T (TSN base).
    These industrial Ethernet specifications allow extremely high-precision synchronization of 1 us or less between devices on the network.

    In evaluating the Back-to-Back connection of the DP83867E SGMII EVM, we are verifying whether operations including ensuring the synchronization accuracy described above are possible.
    In the case of TSN networks, we know that there are methods such as compensating for the transit delay of repeater equipment using IEEE1588 transparent clock technology. However, if possible, I am wondering if it would be possible to use something like the DP83867E, which has extremely low transit delay, to achieve this without incorporating special elements such as transparent clock technology.

    However, after actually evaluating the Back-to-Back connection of the DP83867E SGMII EVM, it seems difficult to achieve synchronization accuracy of 1 us or less for both 100BASE-TX and 1000BASE-T in this form.

    For 100BASE-TX, you suggested the DP83826, but for our own convenience, we would like to convert the back-to-back connection part that is MII or RGII to SGMII. This is due to the convenience of the equipment we are considering, but we want to reduce the number of connected signals as much as possible.
    Are there any TI products that can be configured like the DP83826 + [MII or RMII to SGMII conversion]?

    Regarding 1000BASE-T (TSN base), it would be very helpful if there is any current confirmed results.
    For this, SGMII is ideal for the back-to-back connection.

    thank you.

  • Hello,

    Thank you for your reply. David will be replying back starting next week.
    Sincerely,
    Gerome

  • Hello.

    Thank you for checking and investigating.
    What do you think of the situation after that?

    Is it possible to achieve high-precision inter-device synchronization performance in various types of industrial Ethernet using only the DP83867E's back-to-back connection?
    As mentioned in the previous post, we have already completed verification using the EtherCAT system. There may be a problem with our verification, so we would like to refer to TI's verification and actual results.

    TI has already prepared products that support various types of industrial Ethernet, and seems to have a sufficient testing environment, so we have high expectations for TI's opinions.

    Thank you for your continued support.

    Thank you.

  • Hi Toshikazu,

    As stated, you may try the same experiment with 826EVMs back to back for EtherCAT. Have you tried the DP83867 with CC-LinkIE?

    I am not sure if it will be possible to achieve what you are attempting, without using the transparent clock feature. I will consult with the team once again and get back to you on Monday

    Thanks,

    David

  • Dear David,

    Thank you for your confirmation and reply.
    "CC-LinkIE TSN" is also evaluated with DP83867E.
    We are also considering devices compatible with "CC-LikIE TSN".

    To support "CC-LikIE TSN," the device is configured using Renesas Electronics' "R-IN32M4-CL3" SoC.
    The current situation is that we have confirmed that devices are synchronized with high precision, but it is difficult to confirm the synchronization accuracy.
    Although it is a simple measurement, we have confirmed synchronization within ± several microseconds within the standard specification of 1 microsecond. Accurate measurements now require advice from SoC vendors.
    I would like to wait for the confirmation status there.
    Regarding the case of "EtherCAT" in DP83867E Back-to-Back, if you can confirm the situation, it would be helpful if you could also tell us about it. The situation confirmed here is the same as the measured waveform in the previous post. We are unable to meet the standard specification of 1 us or less.

    Also, there was talk about how to implement this using the transparent clock function, but I wonder if there are any technical manuals or application notes on how to configure devices that use the transparent clock function with TI products. Could you please give me some advice?
    I would like to consider this together.

    Thank you for your support.

  • By the way,
    "CC-LinkIE TSN" is a "TSN" based protocol, but by chance we are just considering "CC-LinkIE TSN" compatible equipment. High-precision synchronization between devices is achieved using "TSN", so verification using "CC-LinkIE TSN" is not necessarily required.

  • Hi Toshikazu,

    I checked with the team and unfortunately we do not have any options to reduce the latency variation. You may try with the DP83826 as mentioned earlier.

    In regards to transparent clock function, here is an app note describing transparent clock operation with the DP83640. Note that a controller (not present on the DP83867 EVMs) must be used to handle operation of the protocol as well as generation, termination, and modification of PTP packets. 

    Thanks,

    David

  • hello David,

    Thank you for confirming.
    Does that mean that the DP83826, which supports 100Mbps, has less delay? I got it.
    However, it is a pity that SGMII cannot be selected as the MAC interface. For the convenience of this product, I would like to reduce the number of signals on the MAC interface as much as possible. SGMII is the most likely candidate, but this is why we chose DP83867 as a candidate that can select SGMII and also support Gbit.
    If you choose DP83826, it will be an MII or RMII interface, but you will probably need a separate circuit element to convert it to SGMII. In the end, I imagine that adding this will result in a delay equivalent to DP83867.

    Thank you for introducing the application material (DP83640) regarding transparent clocks. I have already seen these materials.

    On top of that, it would be ideal to have a product that supports Gbit and SGMII in addition to a timestamp function equivalent to the DP83640. Does TI have any plans to release Gbit compatible products like this in the future?

    I apologize for asking this question over and over again.
    Thank you.

  • Hi Toshikazu,

    Thank you for the feedback, I will bring this to the team and take note for future products.

    I cannot comment on future device plans on the public forum. Please reach out to your field representative for questions on the roadmap devices.

    Thanks,

    David 

  • hello David,

    thank you for your reply.
    I understand that I cannot present TI's product roadmap here.

    I would like to take a look at TI's product release trends in the future.

    Thank you for your support.