DP83867IS: About Gigabit Master Scramble Mode

Hi Atsushi-san, 

I am not sure what the exact functionality is described by legacy vs normal mode. This setting changes the scrambling/descrambling methods within the PCS block of the PHY for gigabit applications. 

I will try to get more information about this function from our design team internally, but that could potentially take 1-2 weeks. 

The legacy mode should not be used for normal operation. I can see that the bit is read only, so it must have been toggled through something else. 

Were you able to perform an ABA swap to see if this behaviour is taking place with the specific STB link partner? Perhaps another 867 can be used as a link partner to see if the same behaviour is observed.

Best,

Vivaan

Hi Vivaan-san,

Thank you for your reply.

I'm looking for hearing more about legacy mode and normal mode.

Do you know why the user shouldn't use legacy mode?

However, as you say, it's read-only, so users can't change it.

Please let me know if there is a solution for this case.

I'm requesting an ABA swap, but it may take some time to prepare the environment.

In the meantime, we would like to explore other approaches.

Hi Atsushi-san,

Atsushi Takahashi said:

Do you know why the user shouldn't use legacy mode?

I believe its because this setting changes the scrambling method within the gigabit PCS (Physical Coding Sublayer) block. It could be that this scrambling method is different from the one the link partner is using, which would explain why the packets aren't being read properly, because they are being encoded and decoded using different methods.

I will try to get our design team to answer this in more detail and get back to you by the end of next week

Best,

Vivaan

HI Atsushi-san, 

Thank you for your patience. 

I have spoken with our design team and confirmed that this mode's function was for interoperability with a specific PHY. The 867 is supposed to automatically detect if this PHY is the link partner and configure this setting. 

I believe this setting is being incorrectly toggled here. Writing 0x50[1] = '0' should disable this feature. 

Do try this and let me know if it helps with the packet loss behaviour.

Best,

Vivaan

Hi Vivaan-san,

Thank you for your update.

I'll try to write 0x050[1]=0.

What is a specific PHY?

Please tell me the detail within you grasp.

Hi Atsushi-san,

This mode should be enabled for connecting with another link partner PHY, not the Realtek PHY in this case. I am not sure what specific PHY this is, but it should not be toggled for the Realtek PHY. 

Best,

Vivaan

Hi Vivaan-san,

My customer read 0x50 in order to try to write 0x50[1]=0.

Bit[1] was already "0".

From this, it seems that Legacy mode is disabled.

When 0x50[1]=0 and 0x17[8]=1, is the PHY set to Normal mode or Legacy mode?

How can we switch to Normal mode?

Hi Takahashi-san,

Thank you for your query. Vivaan is OoO today, and will be looking to respond to your query by EoD Wednesday.

Sincerely,

Gerome

Hi Takahashi-san, 

It is possible that this bit 0x50[1] behaves differently. Can the customer try writing it to 0 even if it already reads as 0? I believe it may act as a latch switch such that writing this bit may disable legacy mode. I am unable to reproduce the issue here, so I wanted the customer to try this.

I am still talking with the design team internally and will update you on any progress on that front. 

Best,

Vivaan

Vivaan-san,

Thank you for your reply.

I'll ask my customer to write 0x50[1]=0.

After writing, would you expect to read register 0x17[8]=0(Normal mode)?

Or will it remain register 0x17[8]=1(Legacy mode)?

Hi Takahashi-san, 

Since I am not able to test this in the lab, I am not sure what behaviour we expect. Here are a few situations that might arise after writing the register.

It may be that if the register is written while the legacy mode link is active, the PHY drops the link and re-negotiates a different link with 0x17[8]=0(Normal mode)

It could also be that the PHY internally switched the legacy mode option off, but it is not reflected in the register setting. In this case, 0x17[8]=1, but I would like customer to continue the test with sending data to see if internally it was fixed or not

It may be that if the link is already established, writing this register does not change the current link mode. In this case, maybe customer can try writing this register before trying link up. 

Best,

Vivaan

Hi Vivaan-san,

My customer wrote 0x50[1]=0, however, anything was no changed.
Communication problem occurred again after that.

We have additional questions.

1) How is Legacy mode and Normal mode determined specifically?
2) How does it behave in Legacy mode specifically?
3) Is register 0x50[1] really a register that disables Legacy mode?
4) The communication problem this time seems to be caused by something else, but is Legacy mode error setting issue a problem that must be solved?

Best Regards,

Hi Takahashi-san, 

Thank you for trying the register 0x50. I am not sure why it did not work. I will contact our design team and try to get an answer for this as soon as possible. 

Atsushi Takahashi said:

1) How is Legacy mode and Normal mode determined specifically?
2) How does it behave in Legacy mode specifically?

Unfortunately, I am not very familiar with these details, but I will get an answer from the design team and reply back in about a week

Atsushi Takahashi said:

3) Is register 0x50[1] really a register that disables Legacy mode?

I was told that this bit should disable legacy mode from our design team, but I was not able to replicate the issue myself to actually test this. I will be asking the design team and try to get clarity on how to disable this mode. 

Atsushi Takahashi said:

4) The communication problem this time seems to be caused by something else, but is Legacy mode error setting issue a problem that must be solved?

What makes you say that the behaviour this time was caused by something else? Was legacy mode not enabled in the register in this test case? From my understanding, the legacy mode changes the encoding structure which explains the packet loss observed. 

Best,

Vivaan

Hi Vivaan-san,
Thank you very much for your continued support.

This problem has been going on for a long time.
Due to the strong request of the customer, this problem needs to be resolved quickly.
It would be appreciated if you could provide us with information about Legacy mode as soon as possible.
I'm sorry for bothering you.

You said:
What makes you say that the behaviour this time was caused by something else? Was legacy mode not enabled in the register in this test case? From my understanding, the legacy mode changes the encoding structure which explains the packet loss observed.

It is true that the device is set to Legacy mode at communication problem.
However, we cannot determine whether this is really a problem or not because there is little information about Legacy mode.
We need more information about Legacy mode to clarify what the real problem is.

Additional questions:
5) Is register 0x50[1] a register that is reset when the link goes down? Or is this value retained even if you reset the HW after writing it once?

In addition to 1) to 4) above, I would appreciate it if you could also check this.

Hi Takahashi-san, 

I understand the urgency, I have reached out to out design team and am hoping to find some clarity about this in the next few days. Thank you for your patience. 

Atsushi Takahashi said:

5) Is register 0x50[1] a register that is reset when the link goes down? Or is this value retained even if you reset the HW after writing it once?

After a reset, all registers are reset to the default values, including register 0x50

Best,

Vivaan

Hi Vivaan-san,

Thank you for your reply.

I’m sorry.

My question wasn't precise.

If they write 0x50[1]=0 while link is up and then the link goes down, will this bit be cleared?

The customer writes this bit during link-up, and then repeats link-down and link-up several times, which reproduces the communication failure.

They need to repeat this several times because the frequency of communication failure is not 100%.

I thought that if this bit is reset when the link goes down, this verification would not be effective.

Hi Takahashi-san, 

I do not have all the information about this but, but I do not think that it should be reset after re-linking. I will further clarify this from the design team as well. 

Best,

Vivaan