DP83869HM: 1DFh register, RGMII-to-SGMII bridge mode

Hi Oba-san, 
That is interesting. I just tried it on the EVM and I did not see this issue. Can you verify that they wrote using the extended register access by using register 0xD and 0xE? For C00h, this can come out as 0x1140 since 00h is 0x1140 by default. 

Best,
J

Hello J,

Thanks for your reply.

I asked if they are using extended register access. Their answer was yes.
Since they can read STRAP_STS correctly, the way of extended register access should be fine.
I'm not sure if it is helpful, but I received their schematic.
I will send it by email to you soon.

Regards,
Satoshi Obata

Hi Obata-san, 

I reviewed the schematic and I have a few questions:
1. What is the value of the pull-up resistor on the MDIO line?

2. We typically recommend to use one resistor for RBIAS and not put them in series. 

Based on the schematic, I do not see a reason why there can be read failures on specific registers. Have they read the register multiple times, and can ensure the write was done?

Also, to answer your question on the first post, yes because they strapped the PHY, additional register writes are not necessary and strap setting may not be reflected in the register configuration so that is expected if the customer is worried about that. 

Best,
J

Hello J,

A1) The pull-up value on MDIO is 2.2Kohm.

A2) When using two series resistors instead of one resistor for RBIAS, is there any possibility to prevent the SGMII connection between both PHYs?
What kind of effect could it have?

A3) When reading the register multiple times, the read value was the same, 0x0000. When trying to read the default value, it was also 0x0000.

Question: Is it OK to think LINK_STATUS_2 in PHY_STATUS register = 1 means the link is established?

Regards,
Oba

Hi Oba-san, 

Oba said:

A2) When using two series resistors instead of one resistor for RBIAS, is there any possibility to prevent the SGMII connection between both PHYs?
What kind of effect could it have?

There is a voltage reference inside of the PHY that sets up a known current through the RBIAS resistor. We have seen different MDI characteristics from different RBIAS resistance, and there can be functional impacts also. Is the customer not seeing SGMII connection?

If the customer has a logic analyzer, could they can read the MDIO signals when this specific register is being read?

LINK_STATUS_2 is good to be used for link status.

Best,
J

Hello J,

They tried to change the 2 series RBIAS resistors to one single resistor. But it didn't improve it at all.

The below is their connection and the SGMII connection ("=") is not established.

CPU-----DP83869HM=DP83869HM-----CPU

They took an oscilloscope waveform. I'll send it in separate mail.

Regards,
Oba

Hi Oba-san, 

If the SGMII connection is not established, have they checked out our SGMII troubleshooting guide?
Could they check bit 1 and 2 of register 37h? This indicates if the SGMII auto-negotiation is complete and if the page is received. 
I looked at the MDIO/MDC waveform but I cannot really decode what is going on. I would suggest the customer to use the logic analyzer. Also, as a sanity check, I suggest the customer to read back 0x0D/0x0E registers after they do each write for the extended register MDIO operation. 
Just to confirm, is the customer doing the following writes/reads to read the register 1dfh?

Register Address  Write Value
000D                      001F (W)

000E                      01DF (W)

000D                      401F (W)

000E                       (R)

Best,
J

Hello J,

>If the SGMII connection is not established, have they checked out our SGMII troubleshooting guide?

I have informed it to the customer and they will check it.

>Could they check bit 1 and 2 of register 37h? This indicates if the SGMII auto-negotiation is complete and if the page is received. 

I believe that you mean bit 0 and 1. Anyway, 37h is 0x0001 which means "autonegotiation process completed"
Do you see anything from it?

>I looked at the MDIO/MDC waveform but I cannot really decode what is going on. I would suggest the customer to use the logic analyzer. Also, as a sanity check, I suggest the customer to read back 0x0D/0x0E registers after they do each write for the extended register MDIO operation. 

They will check it.

>Just to confirm, is the customer doing the following writes/reads to read the register 1dfh?

Yes, they did the exactly the same sequence for 1dfh write/read.

Regards,
Oba

Hi Oba-san, 

Oba said:

I believe that you mean bit 0 and 1. Anyway, 37h is 0x0001 which means "autonegotiation process completed"
Do you see anything from it?

Yes, I meant bit 0 and 1. Thanks for verifying it on your end. It is a status flag to see if the autonegotiation was completed. Bit 1 shows if next page from the SGMII MAC was received. This is important since the MAC needs to send the next page for auto-negotiation to be complete.

Oba said:

>Just to confirm, is the customer doing the following writes/reads to read the register 1dfh?

Yes, they did the exactly the same sequence for 1dfh write/read

Okay, in this case, the logic analyzer may be our best debug method. Based on the waveform, it looks like the read is 0h but the logic analyzer will be able to decode better. 

Also, it may be possible it is taking some time for the PHY to grab the correct read data. Could they read 0E multiple times to see if the value gets updated?

Best,
J

Hello J,

One additional question.

They can see 
Bit 2 of BMSR(1h), LINK_STS1=0 
and
BIT10 of PHY_STATUS(11h). LINK_STATUS_2=0
It means it is link down. Is this understanding correct?

Regards,
Oba

Hi Oba-san,

Your understanding is correct. But, please note that the link status will not go high in bridge mode.

Best,

J

Hello J,

After reading back 0x0D and 0x0E, they finally found that there was a mistake for extended register access.
Thanks for your help. Now they can read 1DF register as 0x0003.

But they says that the link is not still established. 
You mentioned that the link status will not go high in bridge mode.
How to check if the link is established?

The below is their register dump.

0x0000 = 0x2100 : BMCR

0x0001 = 0x7949 : BMSR
0x0011 = 0x6802 : MII_REG_11
0x0428 = 0x0000 : A2D_REG_40
0x045D = 0x0000 : SORVECTOR_1
0x0608 = 0x0000 : SGMII_CTRL_1
0x060A = 0x0000 : SGMII_STATUS
0x060C = 0x0000 : SGMII_CTRL_2
0x060D = 0x0000 : SGMII_FIFO_STATUS
0x0639 = 0x0000 : PKT_STAT_1
0x063A = 0x0000 : PKT_STAT_2
0x063B = 0x0000 : PKT_STAT_3
0x063C = 0x0000 : PKT_STAT_4
0x063D = 0x0000 : PKT_STAT_5
0x063E = 0x0000 : PKT_STAT_6
0x0000 = 0x2100 : BMCR
0x0001 = 0x7949 : BMSR
0x0014 = 0x29c7 : GEN_CFG2
0x0031 = 0x10f0 : GEN_CFG3
0x0037 = 0x0003 : SGMII_AUTO_NEG_STATUS
0x0010 = 0x5c48 : PHY Control Register
0x0017 = 0x0040 : Status Register 2
0x001E = 0x0012 : Configuration Register 3
0x001F = 0x0000 : Control Register
0x006E = 0x1640 : Strap Status Register
0x01DF = 0x0043 : OP_MODE_DECODE
0x0C00 = 0x1140 : Fiber Control Register
0x0C01 = 0x6169 : Fiber Status Register
0x0C19 = 0x0001 : Fiber Interrupt Status Register

And they have another question. According to "SGMII trouble shooting guide", it says "

"if SGMII link up is still unsuccessful, the auto-negotiation timer can also be adjusted for some TI Ethernet PHYs so that the entire auto negotiation cycle is slower or faster on the PHY side."

Is this "autonegotiation cycle" BIT6-5 of GEN_CFG3 (31h), SGMII_AUTO NEG_TIME?

Regards,
Oba

Hello J,

They finally confirmed it worked well after changing their code to use bit0 of 37h to know the link establishment.
Thanks for your support.

Regards,
Oba

Hello J,

After they changed their S/W, they found that they still had a problem for this connection.

Now the connection is like the below.

CPUA-----DP83869HM=DP83869HM-----CPUB

When sending PING from CPUA to CPUB, it didn't succeeded with "RGMII-SGMII Bridge mode", but it succeeded with "RGMII-to-1000Base-X Mode".

Do you know why "RGMII-to-1000Base-X Mode" works for this connection?
How to change their setting to work with "RGMII-SGMII Bridge mode"?

Regards,
Oba

Hello J,

Thanks for your reply.

Regards,
Oba

Hello J,

The customer has some additional questions for this topic.

1)
They would like to know the resistor setting when 2 PHYs are connected by SIO.

2)
What is the difference between "RGMII-to-1000Base-X Mode" and "RGMII-SGMII Bridge Mode"?
They would like to understand the purpose and how to use it for each mode.

3)
If there is a possibility that their H/W could have something wrong, they would like to know it.

Regards,
Oba

Hi Oba-san, 

1. What is SIO?
2. The difference between RGMII to 1000Base-X and RGMII to SGMII mode is that 1000Base-X is designed for fiber and SGMII is designed for SGMII signal. However, signaling for fiber and SGMII are both LVDS. In the SGMII case, the PHY expects to do SGMII auto-negotiation with the SGMII MAC or the PHY (depending on the configuration) while fiber will conduct fiber auto-negotiation with the fiber link partner. 
3. Are they seeing any issue? I currently do not see any HW issue with the information I have. 

Best,
J

Hello J,

>1. What is SIO?

Regarding SIO in your question, it means SIP/SIO/SOP/SON cross connection between 2 DP83869HMs. Sorry for unclear wording.

>3. Are they seeing any issue? I currently do not see any HW issue with the information I have. 

The background of this question is that it didn't work with RGMII-SGMII Bridge mode.
On the other hand, RGMII-to-1000BaseX mode works well. They want to know the reason.

>2. The difference between RGMII to 1000Base-X and RGMII to SGMII mode is that 1000Base-X is designed for fiber and SGMII is designed for SGMII signal. However, signaling for fiber and SGMII are both LVDS. In the SGMII case, the PHY expects to do SGMII auto-negotiation with the SGMII MAC or the PHY (depending on the configuration) while fiber will conduct fiber auto-negotiation with the fiber link partner. 

From this answer, they understand that the difference in RGMII/SGMII bridge mode is doing SGMII auto negotiation.
Does it mean auto negotiation was failed or not completed in their board with this bridge mode?

Regards,
Oba