DP83867IS: Inquiry on PHY Behavior and Required Handling When GMAC is Reset Without PHY Reset under SGMII

Hello,

In your described scenario, I would expect PHY operation to continue. The only impact that MAC resetting would have on the signal chain would be for SGMII auto-negotiation to be redone as you are describing. I would suggest restarting the auto-negotiation on the PHY by either toggling Reg 0x14[7] or Reg 0x10[11].

Sincerely,
Gerome

Dear Gerome Cacho san,
Thank you very much for prompt reply. Noted,

>>I would suggest restarting the auto-negotiation on the PHY by either toggling Reg 0x14[7] or Reg 0x10[11].
   => Let me confirm the concrete action "either" you said means "or", correct?
   In addition, "Toggling" you said means that once disable after that enable, right??

Best Regards,
        Asano

Hi Asano-san,

• Yes, your understanding is correct that this means "or". You can try both of these options. 
• That is correct.

Best regards,

Greg

Dear Greg san, Thank you for your confirmation and your kindly suggestions.

## THIS IS Additional Questions ##
We would like to ask a few follow-up questions regarding your advice.

[1]
■What I did■
I tried "toggling the register" on our prototype.
However, when I toggle Reg 0x10[11], the link between PHY and the other PHY is temporarily disconnected, resulting in a re-link-up sequence. This behavior does not meet our intended requirement, which is for the PHY to maintain link-up continuously.
■Request■
Could you please confirm whether our understanding is correct that this behavior is expected, and therefore this method may not be suitable for our purpose?

[2]
■What I did■
I also tried toggling Reg 0x14[7], but the situation did not improve and communication still failed.
Therefore, we believe this method is not effective in our case.
■Request■
Could you suggest any alternative approach?

[3]
■What I did■
In the Application Note <SGMII Troubleshooting Guide> section "1.3 Auto-Negotiation",
it is stated:
"If the PHY comes up before the MAC, a SGMII restart can be required for the MAC to receive control information for successful link up."
■Request■ 
I would like to confirm whether this statement applies to our case, where only the GMAC is restarted.
If yes, the note mentions an "SGMII restart." Could you please clarify what specific operation this refers to? Is it the same action with "toggling 0x10[11]" or not??

Best regards,
          Asano

Hi Asano-san, 

I will check on these questions and will get back to you as soon as possible.

Best regards,

Greg

Dear Greg,
Hi, thank you for your kindly reply.

Hi Asano-san,

Since in SGMII mode the PHY sends link status and speed parameters during startup, it may be an issue on the MAC side not synchronizing with SGMII after the reset. What reset is being done with the GMAC, and is there any re-initilization?

Yuuichi Asano said:

Could you please confirm whether our understanding is correct that this behavior is expected, and therefore this method may not be suitable for our purpose?

You are correct, this method looks to not be suitable for your application.

Yuuichi Asano said:

If yes, the note mentions an "SGMII restart." Could you please clarify what specific operation this refers to? Is it the same action with "toggling 0x10[11]" or not??

Yes, this is the same action as toggling 0x10[11]. Can you please read registers 0x60A, 0x60C, and 0x60D after the GMAC reset?

Best regards,

Greg

Dear Greg san, thanks for your reply.

■Question from Greg san■
>>it may be an issue on the MAC side not synchronizing with SGMII after the reset. What reset is being done with the GMAC..
■Answer■
In the scenario where the PHY remains powered while the GMAC undergoes a reset and restart,
I perform the same re-initialization process on the GMAC as is done during power-up.
For reference, at power-up, communication between the PHY and GMAC works correctly without any issues.

■Question from you■
Could you please read registers 0x60A, 0x60C, and 0x60D after the GMAC reset?
■Confirmation■
I would like to confirm whether the registers 0x60A, 0x60C, and 0x60D also exist in the target device DP83867IS or not.
Based on our understanding of the SGMII Troubleshooting Guide,
registers 0x60A (SGMII_STATUS), 0x60C (SGMII_CTRL_2), and 0x60D (SGMII_FIFO_STATUS) appear to be SGMII-specific registers for a different device (DP83TG720S-Q1 Automotive PHY).
Additionally, these registers do not seem to be present in the datasheet of the target device DP83867IS.

■Re-confirmation from Asano■
Please answer whether my understanding ①–③ is correct with YES or NO.

Hi Asano-san,

Yuuichi Asano said:

■Confirmation■
I would like to confirm whether the registers 0x60A, 0x60C, and 0x60D also exist in the target device DP83867IS or not.

This is my mistake. We would like to see registers 0x0000, 0x0001, 0x0014,  0x0031, 0x0037 on the DP83867. 

What is the software logic for the GMAC restart? Does it read or write to any PHY registers?

Yuuichi Asano said:

When only the GMAC is reset and restarted while the PHY remains powered on, it is necessary to restart the SGMII, which is the interface between the PHY and GMAC, in order to re-establish communication after the GMAC restarts.

This may not be the case, cannot give Yes or No yet.

Yuuichi Asano said:

② The SGMII restart can be achieved by toggling the PHY register (address 0x10, bit [11]). However, this operation causes link down and subsequent link up between the PHY and GMAC, as well as between the PHY and the remote PHY.

Yes, this is correct, this is how the SGMII link is enabled/disabled. From your testing it seems that the link drops after this register write. 

Yuuichi Asano said:

③ Based on ① and ②, when only the GMAC is reset and restarted, it is an unavoidable specification that link down and subsequent link up will occur on the PHY in order to re-establish communication after the GMAC restarts..

This is what we are trying to determine. I cannot give a Yes or No to this yet, as we are trying to determine if something in the GMAC reset process could trigger the SGMII link to drop. 

Best regards,

Greg

> Gregory Kobyakov  said: > to see registers 0x0000, 0x0001, 0x0014,  0x0031, 0x0037 on the DP83867.
■Answer■
The bit values of the specified registers were observed as follows.
The observation condition was that sufficient time had elapsed after restarting only the GMAC. At this point, packet transmission and reception had not been achieved.

0x0000: 0x1140
0x0001: 0x796D
0x0014: 0x29C7
0x0031: 0x10B0
0x0037: 0x0000

> Gregory Kobyakov said; >What is the software logic for the GMAC restart? Does it read or write to any PHY registers?
■Answer■
GMAC block in FPGA is CoreTSE v3.2 by Microchip and the block can be reset by setting the GMAC resister.
So, No any PHY registers are write or read to reset GMAC block.

Best regards,
          Asano

Hi Asano-san,

Thank you for the clarifications. Can you please send a PHY register dump before and after the GMAC reset? Specifically registers 0x0000 - 0x0020, 0x006E,0x006F, and the ones I requested earlier.

Best regards,

Greg

Dear Gregory Kobyakov  san, at first, refer to  a PHY register dump before and after the GMAC reset you requested earlier.

Note: Row 5 (SGMII_AUTO_NEG_STATUS) shows the value changing from 0x0001 at startup to 0x0000 after restart — the only register that differs between the two states.

Dear Gregory Kobyakov  san, please refer to  ALL OF PHY registers dump before and after the GMAC reset you requested.

Hi Asano-san,

Thank you for sharing this read, I will look over it and provide comments.

Best regards,

Greg

Dear Gregory Kobyakov  san,
Thank you for your continued support. Noted, but I would like to ask a few additional questions.

■Question 1■ In the case where the SGMII Enable signal is first set to Disable, and then set to Enable again:
Does this operation result in re–auto-negotiation between the local PHY and the local GMAC in practical use?
Additionally, how does this affect auto-negotiation between the local PHY and the link partner PHY?
Will re–auto-negotiation also be performed on the copper link side?


■Question 2■ Regarding the SGMII restart from the PHY perspective:
Is toggling register 0x0010[11] the only available method?
Is there any other way to achieve SGMII re-synchronization without causing a link drop?
Alternatively, could this be avoided by proper handling on the GMAC side?

■Question 3■
To help investigate whether the GMAC reset process may contain factors that cause the SGMII link to drop,
what kind of information would be most useful from our side? Would it be more helpful to provide:
the detailed GMAC initialization sequence during power-up and restart, or
the exact shutdown sequence executed when the GMAC is reset?
We would like to provide sufficient information to support effective analysis on both sides.

Best regards,

    Y Asano

Hi Asano-san,

Yuuichi Asano said:

In the case where the SGMII Enable signal is first set to Disable, and then set to Enable again:
Does this operation result in re–auto-negotiation between the local PHY and the local GMAC in practical use?
Additionally, how does this affect auto-negotiation between the local PHY and the link partner PHY?
Will re–auto-negotiation also be performed on the copper link side?

This should result in the link negotiation to restart between the PHY and GMAC in practice use. However, it should not necessarily cause MDI link down. 

Yuuichi Asano said:

■Question 2■ Regarding the SGMII restart from the PHY perspective:
Is toggling register 0x0010[11] the only available method?
Is there any other way to achieve SGMII re-synchronization without causing a link drop?
Alternatively, could this be avoided by proper handling on the GMAC side?

0x0014 also does this, but it seems this was not successful either during your testing

Yuuichi Asano said:

■Question 3■
To help investigate whether the GMAC reset process may contain factors that cause the SGMII link to drop,
what kind of information would be most useful from our side? Would it be more helpful to provide:
the detailed GMAC initialization sequence during power-up and restart, or
the exact shutdown sequence executed when the GMAC is reset?
We would like to provide sufficient information to support effective analysis on both sides.

Yes, the GMAC initialization sequence used by the GMAC during power-up and restart would be useful. Is there any difference in SGMII signals (maybe taken via probing) during start-up vs restart?

Best regards,

Greg

Dear Gregory Kobyakov  san,
Hi, this is Asano.

>>, I will look over it and provide comments.
 Regarding you mentioned earlier as above, Could you please update me on the progress of the questions I asked?

Dear Gregory Kobyakov  san, you said: 
>> GMAC initialization sequence used by the GMAC during power-up and restart would be useful.
--> So, let me share initialization sequence applied to GMAC at power-on and the restart, as shown below.
--> Note that the same initialization sequence is used for both power-on and restart.
--> For detailed info of each register, please also refer to the GMAC datasheet available at the below URL.
--> CoreTSE User Guide

Hi Yuuichi-san,

Gregory is out of office today and will return next monday

BEst,

Shane

Shane Hauser  san, Hi, this is Asano.
Noted, thank you very much for your kindly contact.
I would like to wait the reply. 

Best REgards,
    Asano

Hi Asano-san,

Thank you for providing the requested info. We have tested with our EVM for the device, and SGMII enable/disable should not affect the MDI connection. This is why I believe this issue is being caused by the MAC.

Best regards,

Greg

Dear Gregory Kobyakov  san,
Hi, this is Asano.

Thank you for your kindly evaluation and detailed feedback.
I understand your findings.

After internal discussion with our GMAC team, we have decided to proceed with the following design change on GMAC block