DP83867E: About Back-to-Back connection using SGMII interface of DP83867E

Hi Toshikazu,

DP83867 does not support link loss forwarding - it is not possible to automatically drop the far-end link without adding application-level logic polling the link status of one PHY and using this information to have an MCU/MPU drop the link of the other PHY.

Can you help me understand the application requirements for dropping the far-end link?

Thank you,

Evan

Hello Evan,

Thank you for answering.

DP83867E does not support link loss transfer...
Also, add application level logic to poll the link status of one PHY and use this information to automatically drop the far-end link without forcing the MCU/MPU to drop the link of the other PHY. I can't even do that. It is that···

For our application, we are considering products that support Gbit/100Mbit industrial Ethernet. More specifically, we are considering a repeater device configured by connecting DP83867E back-to-back using SGMII. However, the back-to-back connection part is made non-contact (physically isolated).
A repeater device falls under an infrastructure device, but in order to treat it like an Ethernet cable, I would like a loss of link on one Ethernet port to function as a loss of link on the other Ethernet port (a transparent device ).

I am wondering if it would be possible to notify the other DP83867E of the link drop via SGMII by notifying the link drop detection result of the DP83867E and disconnecting the port, etc. to the destination connected to that port.
To make the connection destination detect a link drop,
(1) Power down DP83867E
(2) Set DP83867E to Standby mode
I think you can also use brute force methods such as: After that, when the link drop detection source is linked up again, the DP83867E will be restarted in normal operation mode.
However, a method is required to notify link-up and link-down to the back-to-back connection of SGMII, which is to be made contactless. Furthermore, even if this could be done somehow, a means to power down or transition to Standby mode (such as a notification signal to an external MPU, etc.) would also be required.

I guess it's unreasonable after all...

Are there any other devices that have functions and performance equivalent to the DP83867E and can meet the above requirements?

Thank you.

Hello Evan,

Please let me add something.

According to the explanation in "Control Information Exchanged Between Links" of CISCO SYSTEM's SGMII specification (Document Number: ENG-46158), information regarding Link up, Link down, Duplex, Speed, and Auto-negotiation is reported. However, is there any way to check this information via registers on DP83867E?

caxapa.ru/.../SGMII_.pdf

I don't really want register polling by an external MPU, etc., but I thought it would be possible.

Thank you.

Hi Toshikazu,

I cannot access the Cisco specification, could you please send the PDF to me at e-mayhew@ti.com?

From my understanding, it won't be possible to use the SGMII MAC signals to automatically report link loss. Auto-negotiation does report link/speed/duplex settings over SGMII to the other PHY, but this information is only used such that the PHYs can match configurations to link up and communicate.

I am checking with the team if there are other options for this without external register polling.

Is back-to-back SGMII a strict requirement for your application, or are other 100/1000M industrial repeater-type topologies acceptable (RGMII to SGMII, copper to fiber media conversion, ...)?

Thank you,

Evan

Hello Evan,

Thank you for your response.
The Cisco SGMII specification PDF file will be sent to Evan at e-mayhew@ti.com.

The specifications for exchanging link-up and link-down notifications between back-to-back connections via SGMII, and for referencing this information on MPUs, etc., can be found in the DP83867E data sheet (latest Rev.D). I can't find it in the published specifications. I don't think it's possible to do something like that.
There is a problem in trying to make the internal structure of the device we are considering contactless (physically insulated), but if notifications cannot be exchanged via SGMII, we will try another contactless notification route. Must be considered. However, this is something you want to avoid as it makes the device more complex.
I wish there was a better way...

To detect a link drop to the other party connected to the Ethernet port, use Power Down or Standby mode, and to recover, make full use of functions such as TDR diagnosis after a link drop. I feel that there is a possibility.

As a precaution, we are contacting you with the hope that we may be able to respond with undisclosed specifications.

Thank you.

Hi Toshikazu,

Thank you for the additional context on the requirements and specification.

Please allow me some time to discuss internally with the team if there are any options to achieve a contactless setup with link loss pass through.

I expect to confirm if this is possible by Tuesday 3/4.

Thank you,

Evan

Hello Evan,

Thank you for understanding our requirements.
I am glad that you will consider it.

I'm waiting your reply.
Thank you.

Hello Evan,

Supplement.

＞Is back-to-back SGMII a strict requirement for your application, or are other 100/1000M industrial repeater-type topologies acceptable (RGMII to SGMII, copper to fiber media conversion, ...)?

＞

Back-to-back connectivity using SGMII is a mandatory requirement.
This is because we want to reduce the number of signal points as much as possible due to the internal structure to make it contactless.

I'm waiting your reply.
Thank you.

I understand, thank you for confirming.

Please expect a follow-up by Tuesday 3/5.

Best regards,

Evan

Hello Evan,

Thank you for your help.

As I thought.

This challenge addresses the EtherCAT requirements for Industrial Ethernet.
In EtherCAT, when a network cable is disconnected, the port to which the cable is connected must be immediately (<15us) closed (actually a TX/RX loopback procedure).

I was thinking that if I could mutually understand LinkUP/LinkDOWN notifications between the primary and secondary ports of my repeater device via SGMII, I would be able to take a step forward in solving the problem. However, LinkUP/LinkDOWN notifications are statuses that result from Auto-Negotiation. Therefore, the connection partner of this repeater device also opens the port and outputs frames immediately upon completion of Auto-Negotiation. Resuming communication by individually performing Auto-Negotiation on the primary/secondary ports of this repeater device is substantially different from resuming communication by reconnecting the cable.
When using the Auto-Negotiation function, it may be physically impossible to match the completion timing on the primary and secondary ports.

Is there any way to resolve the above concerns?
It would be helpful if there were still options to consider.

Thank you.

Hi Toshikazu,

The only way I can think to resolve this requirement would be to use an EtherCAT compliant MAC (MII/RMII/RGMII) and ESC with DP83867 or DP83869.

Unfortunately there does not seem to be a path forward that resolves the system requirements with SGMII.

Thank you,

Evan