DP83869HM: About DP83869HM bridge mode

Hi Toshikazu,

This is an approximate figure based on my experience, it may be on the order of microseconds.

I can spend time in lab to get a better approximate if you would like confirmation.

Thank you,

Evan

Hello Evan,

thank you for your reply.

Could it be microseconds?
We apologize for the inconvenience, but if there is a possibility, please investigate!

This purpose is based on the industrial Ethernet protocol standard EtherCAT's required specification for port closing operation upon disconnection of the Ethernet line (detect disconnection within 10 us and loop back the port).
Originally, this port close processing is basically performed by the ESC (EtherCAT Slave Controller) rather than the PHY, but we are thinking about whether this could be replaced by the PHY's loopback function for diagnostic functions.

If we can do this, our application can greatly simplify the system configuration and reduce costs.

Is it okay if I ask you a favor?

Hi Toshikazu,

Of course, please allow me some time to verify this for you. Expect a confirmation on this before Wednesday 2/7 next week.

Thank you,

Evan

Hello Evan,

thank you! !

Yes, I'll wait!
I'm looking forward to the results!
Thank you!

Hi Evan,

I'm currently talking about loopback in bridge mode with the DP83869HM, but if possible, it would be best if it could be achieved with the loopback function of the DP83867E.
In the case of DP83867E, the data sheet states that it takes about 500 us. Therefore, I believe that the loopback in bridge mode of DP83869HM may take a similar amount of time.

Based on the above, I am thinking that the only option is to use a device such as DS25MB100 and create a separate loopback circuit in the SGMII signal section.

Thank you.

Hi Toshikazu,

I apologize for the initial confusion about the link detect spec - I have checked with the team and both DP83869 and DP83867 support fast link detect/drop, and are within the timing guidelines for EtherCAT spec (<15us link drop detect).

The 500 us note in DP83867E is in the case of the scrambler losing synchronization - this is not expected to violate EtherCAT specification.

Thank you,

Evan

Hi Evan,

thank you for your reply.

I agree. It seems that Fast Link Drop (FLD) can certainly provide a response of <10 us.

Regarding the DP83867E <500us regulation, can we say that there is no problem with the EtherCAT regulation?
Suppose that EtherCAT switches to loopback mode immediately after FLD detection. In the worst case scenario, if the descrambler goes out of sync and takes 500us to resynchronize, you will lose many EtherCAT frames that could have been used for high-speed process communication.
Shouldn't the <15us or less regulation for link loss in EtherCAT be considered a regulation that also includes loopback switching?
Therefore, I believe that the diagnostic loopback function of the DP83867E cannot be used as a substitute for the port loopback function when EtherCAT link is lost.
(Normally, I think port loopback when EtherCAT link is lost is a function that is handled by the EtherCAT Slave CONtroller (ESC), not the PHY.)

Could you please give me an accurate answer regarding your opinion on this matter?
This is my biggest concern right now. If possible, I would like to deal with EtherCAT line link loss using only the DP83867E's fast link drop (FLD) and diagnostic loopback functions without installing a separate function such as an EtherCAT Slave CONtroller (ESC). Masu.

Thank you.

Hi Evan,

Supplement.

Due to the convenience of our application, we have decided to use SGMII as the PHY-MAC interface of the DP83867E.

As for countermeasures against line link loss in EtherCAT, I am considering the same as in the post I replied to earlier, so loopback of DP83867E cannot be used, and although link loss is detected with FLD, external connection such as DS25MB100 We are currently considering a method to loop back the SGMII signal part in the device circuit.

I was considering the DP83869HM because I was wondering how the DP83869HM would respond to loopback switching compared to the DP83867E's <500 us restriction.

Thank you.

Hi Toshikazu,

After discussing this with the team, I do not think 867/869 are suitable solutions to replace the ESC functionality with the PHY, if meeting Beckhoff ECAT standard is a requirement.

In addition to the possibility of the descrambler losing lock and adding 500us delay, there is additional delay imposed in setting the loopback mode. The SoC needs time to communicate the loopback configuration to the PHY over MDC/MDIO.

Is your application emulating something similar to ECAT, or does it need to meet the ECAT standard? If it must meet the standard, then I expect there to be challenges meeting the timing requirements with a retimer/redriver/PHY emulating the loopback functionality rather than the ESC.

Thank you,

Evan

Hello Evan,

Thank you for your response.

With the DP83867/869, it is impossible to make the ESC's link loss detection and port close (loopback) operations conform to the ECAT standard.

Considering that the descrambler loses synchronization and takes up to 500us to resynchronize, and the time it takes to put the PHY into loopback mode via MDC/MDIO, it seems impossible.

In this application, we are considering developing a repeater-like device whose basic configuration is to connect the SGMII interface of a PHY such as DP83867E back-to-back. However, it is a bit special, but it is necessary to make the back-to-back connection part of SGMII contactless (the part to be made contactless consists of only analog circuit elements and no logic elements, and has already been verified. completed).
The transmission delay of the DP83867 itself is extremely small, and it has performance that can withstand the frame transmission of various industrial Ethernet standards of 100Mbps/1Gbps and the synchronization requirements between devices (<1us). We have also verified normal operation when the line connection is normal.

Among these, only the industrial Ethernet network EtherCAT uses a special communication method and has special requirements when a line link is lost, as in the case of this issue. If this requirement can be met, there is a high possibility that it will be compatible with other communication standards including Gbit, and the cost of equipment can be reduced. Therefore, we are conducting trial and error research.

It would be ideal if the DP83867E could detect line link loss and loop back EtherCAT requests, but that seems impossible. Therefore, we considered a configuration in which DS25MB100 was configured on both sides of the SGMII interface part, which is to be made contactless, to respond to EtherCAT requests with link loss due to DP83867E and loopback using DS25MB100. Please let me talk a little bit about this configuration.
In this case, if a line link loss is detected on one port of the repeater device with this configuration, and if you immediately switch to loopback mode using the switching terminal of the DS25MB100, the scrambler synchronization operation of the DP83867E on the other side with a normal line will be activated. Will there be any impact?
Loopback switching on the DS25MB100 is very fast. Even if an accidental line link loss is detected, I think it is possible to create a loopback path with only a loss of one frame of EtherCAT process communication.

The explanation became a little long. I hope that I can convey this to you well.
Thank you.

Hello Evan,

Please tell us more about DP83867E.

How long does it take to synchronize the DP83867E's scrambler/descrambler?
Also, if these things go out of sync for a moment, how long does it take to get them back in sync?
Furthermore, if one error communication frame is received/transmitted, will the synchronization be easily lost?
It would be helpful if you could also give us some advice.

thank you.

Hi Toshikazu,

Thank you for clarifying the research you are working on.

Although we have seen DP83867/869 in ECAT applications, loopback is not typically used beyond the evaluation/troubleshooting stage.

As a result, we do not not have the data readily available for DP83867 scrambler synchronization time as this is not a spec commonly referenced in applications.

TOSHIKAZU HORI said:

if you immediately switch to loopback mode using the switching terminal of the DS25MB100, the scrambler synchronization operation of the DP83867E on the other side with a normal line will be activated. Will there be any impact?

If a downstream device loops back the data to DP83867 (rather than internal loopback on 867), the synchronizer losing lock should not be a concern. 

Assuming DS25MB100 can meet the same ECAT timing requirements with its faster loopback synchronization, then this may be a suitable alternative.

Thank you,

Evan