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: Regarding LLF(Link Lost Forwarding support

Part Number: DP83867E

Thank you for your help.

We are considering whether the DP83867E can be used as a PHY for industrial Ethernet compatible equipment.
DP83867E supports 100BASE-TX and 10000BASE-T, and we note that it also supports SGMII for our convenience.

The device we are considering is a repeater device configured by connecting DP83867E back-to-back.
I have one point of concern now.
A repeater device corresponds to an Ethernet infrastructure component, and is a measure against the loss of connection with the slave device on the downstream side.
Active infrastructure components, such as repeater devices used in EtherCAT networks, allow the repeater device to maintain a link with the upstream slave device if the hardware connection between the repeater and the downstream slave device is interrupted. It is said that it is necessary to support a mechanism to forcibly connect slave devices on the upstream side.
This mechanism is a specialized mechanism called Link Lost Forwarding (LLF), which works by closing the EtherCAT logical loop with the port to prevent frame loss. This mechanism is included in the EtherCAT slave controller (ESC), and it is recommended to use the ESC for repeaters.
Does the DP83867E have a function equivalent to this kind of mechanism?
If there is a product other than DP83867E that has this kind of compatible function, could you please introduce it as well?

Thank you.

  • Hi Toshikazu,

    Can you share a block diagram of what your desired system would look like? I believe this would be handled by the ESC. For example, with a 2-port Ethercat Device there would be 2 Ethernet PHYs (one on each port) that would be connected to the ESC. The ESC can check the link-status on either ethernet PHY and perform whatever logic.

    Regards,

    Alvaro

  • Dear Alvaro,

    Thank you for your Reply.

    I have attached a system diagram.

    In an EtherCAT network, I would like to connect the DP83867E back-to-back to function as a repeater and insert it as an infrastructure component in the network.
    In this network equipment configuration, when the downstream cable of a DP83867E back-to-back connected repeater is disconnected, the upstream port of the repeater is forcibly connected in loopback using a function equivalent to the Link Lost Forwarding (LLF) mechanism. You need to do it in such a way that
    I don't think the DP83867E has such a function, what do you think?

    Best Regards,

    Toshikazu

    EtherCAT Network System Diagram.pdf

  • Hi Toshikazu,

    Thank you for the diagram. Unfortunately I agree with you, I don't believe the DP83867 will work in this configuration, and if it did I don't believe it will be up to Ethercat's standards.

    Regards,

    Alvaro

  • Dear Alvaro,

    Hello.

    Do you think so?...
    The DP83867E has a loopback test function, and I was hoping that depending on the settings, it might be able to do something equivalent to the LLF function, but unfortunately...

    Are there any TI products that can support these rather special specifications of industrial Ethernet EtherCAT?

    Thank you.

    Best Regards,

  • Hi Toshikazu,

    You're right, the DP83867E has a loopback test function, but it needs to be set up into that mode via register writes. The Repeater block would need two 867 PHYs connected to a Controller (for register access) that can perform the necessary logic. I don't believe it can switch from "Normal Operation" to a loopback mode in a efficient manner. 

    For ethercat, the DP83867 can function as an Ethernet PHY inside the Slave Device.

    Regards,

    Alvaro

  • Dear Alvaro,

    Hello.

    The loopback function provided in the DP83867E is only a function to realize loopback from the MAC control side of the device, and it does not realize loopback to the external side of the PHY, right?

    Although it has been confirmed that there is no problem in the normal operation of the repeater realized by connecting two DP83867Es back to back, the DP83867E does not meet the requirements of EtherCAT when dealing with the upstream port when the connection on the downstream side is disconnected. I don't think it meets the requirements.
    It's still difficult...

    Thank you.

    Best Regards,

  • Hi Toshikazu,

    I want to be clear that the DP83867 meets the EtherCat Standard, however our PHYs are not ESCs (EtherCat sub-device controllers). Our PHY is only meant to pass along data with low latency and logic is to be performed by an ESC. 

    The document linked below, albeit for a different PHY, lists the EtherCat requirements for an Ethernet PHY (Section 2).

    https://www.ti.com/lit/an/snla344c/snla344c.pdf?ts=1699997290455&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FDP83826E

    Regards,

    Alvaro

  • Dear Alvaro,

    Thank you for introducing the application note on EtherCAT for the DP83862E PHY device.

    I understand that these PHY products, including the DP83867E, only serve to pass data to the Ethernet controller at the MAC layer or later with low latency. In the case of EtherCAT, the data is simply passed to the ESC, and the ESC is in charge of operations such as LLF (Link Lost Forwarding).

    We are currently evaluating an actual device using the DP83867E EVM. I just measured the SFD detection timing output signal of the DP83867E and looked at its propagation delay and delay variation. We have confirmed that the delay is extremely low and the variation is very small, and we feel that it can be used in the product under consideration. This device is also Gbit compatible and can support Gbit standard protocols such as CC-LinkIE TSN.
    It seems like we need to configure additional logic to meet EtherCAT requirements.

    We are considering developing an original device such as a repeater that connects DP83867E back to back with SGMII.
    This device aims to be compatible with all industrial Ethernet standards such as 100BASE-TX and 1000BASE-T, but there are some special requirements for EtherCAT, and we are having difficulty deciphering and dealing with them. By the way.

    Thanks to you, my understanding has deepened.
    I would like to do a little more research and deciphering.
    Thank you.

    Best Regards,