Re: In Triple Speed Ethernet core, what does the COPPER_LINK_STATUS refer to?

RMcco · ‎02-21-2019

I'm debugging an Ethernet link that fails after several hours of temperature testing. We're using the TSE core in an Arria 10, configured in the 10/100/1000Mb Ethernet MAC with 1000BASE-X/SGMII PCS configuration, with LVDS I/O.

When the unit is in the failed state, the values in PCS register 0x05 have COPPER_LINK_STATUS=0, COPPER_DUPLEX_STATUS=0, and COPPER_SPEED=00

It's not clear from the documentation - are these registers for the SGMII link between the FPGA and the PHY, or are they trying to pull the status from the PHY of the link between the PHY and the remote device?

Put another way, do these indicate a SGMII problem, or a PHY problem?

RMcco · ‎02-21-2019

Reading through documentation, it looks like the copper status flags are supposed to be coming from the PHY, via the control information SGMII bus. (It would be nice to have that confirmed).

However, I can confirm that the PHY currently believes that the link is up, in 1000Base-T, in full duplex. So there seems to be some issue with the SGMII bus overall.

SengKok_L_Intel · ‎02-22-2019

Hi Ryan, the register 5 of PCS is used for update the partner ability during auto-negotiation. Do you mean, when before the issue happen, the value is 1, but after failure happen, it became 0? Do you perform auto negotiaion? How about other LED status signal before and after failure? Regards -SK Lim

RMcco · ‎02-22-2019

Hi SK -

You are correct - those bits are set appropriately while the link is operating normally, and after it fails, they are set to zero. I am in the process of capturing other before/after data. We are using auto-negotiation.

Can you confirm if the copper status flags are in fact being read by the TSE from data supplied over the SGMII bus? Also, if the TSE does see bad status, will it automatically re-auto-negotiate?

Thanks -

-Ryan

SengKok_L_Intel · ‎02-22-2019

Hi

You can refer to the PCS control register bit 9 and bit 12. Software can trigger the re-start auto-negotiation. If you read those value with zero, i believe the auto-negotiation may be failed. Please capture more status signal to confirm. And how about if your manually trigger the auto-negotiation again? Will it back to normal?

Regards -SK Lim

RMcco · ‎02-22-2019

Hi SK -

I believe I tried restarting auto-negotiation to no effect, but will need to confirm. If it helps, below are register dumps in the good and bad states for the PCS block (note that the addresses are byte addresses and not word addresses). I captured two different failures (rebooted in between and ran until failure again) - they seem to have differences that may be significant.

Also, the PHY we're using is a TI DP83867, if that makes any difference.

Thanks -

-Ryan

Good state:

0x00040a00 0x0000:1140

0x00040a04 0x0000:00a9

0x00040a08 0x0000:0000

0x00040a0c 0x0000:0000

0x00040a10 0x0000:41a0

0x00040a14 0x0000:d801

0x00040a18 0x0000:0003

0x00040a1c 0x0000:0000

0x00040a20 0x0000:0000

0x00040a24 0x0000:0000

0x00040a28 0x0000:0000

0x00040a2c 0x0000:0000

0x00040a30 0x0000:0000

0x00040a34 0x0000:0000

0x00040a38 0x0000:0000

0x00040a3c 0x0000:0000

0x00040a40 0x0000:0000

0x00040a44 0x0000:1101

0x00040a48 0x0000:0d40

0x00040a4c 0x0000:0003

0x00040a50 0x0000:0003

0x00040a54 0x0000:0000

0x00040a58 0x0000:0000

0x00040a5c 0x0000:0000

0x00040a60 0x0000:0000

0x00040a64 0x0000:0000

0x00040a68 0x0000:0000

0x00040a6c 0x0000:0000

0x00040a70 0x0000:0000

0x00040a74 0x0000:0000

0x00040a78 0x0000:0000

0x00040a7c 0x0000:0000

Bad state 1 ( Reg 0x5 = 0x0040)

0x00040a00 0x0000:1140

0x00040a04 0x0000:00a9

0x00040a08 0x0000:0000

0x00040a0c 0x0000:0000

0x00040a10 0x0000:41a0

0x00040a14 0x0000:0040

0x00040a18 0x0000:0003

0x00040a1c 0x0000:0000

0x00040a20 0x0000:0000

0x00040a24 0x0000:0000

0x00040a28 0x0000:0000

0x00040a2c 0x0000:0000

0x00040a30 0x0000:0000

0x00040a34 0x0000:0000

0x00040a38 0x0000:0000

0x00040a3c 0x0000:0000

0x00040a40 0x0000:0000

0x00040a44 0x0000:1101

0x00040a48 0x0000:0d40

0x00040a4c 0x0000:0003

0x00040a50 0x0000:0003

0x00040a54 0x0000:0000

0x00040a58 0x0000:0000

0x00040a5c 0x0000:0000

0x00040a60 0x0000:0000

0x00040a64 0x0000:0000

0x00040a68 0x0000:0000

0x00040a6c 0x0000:0000

0x00040a70 0x0000:0000

0x00040a74 0x0000:0000

0x00040a78 0x0000:0000

Bad state 2 (Reg 0x05 = 0xC2A0):

0x00040a00 0x0000:1140

0x00040a04 0x0000:00a9

0x00040a08 0x0000:0000

0x00040a0c 0x0000:0000

0x00040a10 0x0000:41a0

0x00040a14 0x0000:c2a0

0x00040a18 0x0000:0003

0x00040a1c 0x0000:0000

0x00040a20 0x0000:0000

0x00040a24 0x0000:0000

0x00040a28 0x0000:0000

0x00040a2c 0x0000:0000

0x00040a30 0x0000:0000

0x00040a34 0x0000:0000

0x00040a38 0x0000:0000

0x00040a3c 0x0000:0000

0x00040a40 0x0000:0000

0x00040a44 0x0000:1101

0x00040a48 0x0000:0d40

0x00040a4c 0x0000:0003

0x00040a50 0x0000:0003

0x00040a54 0x0000:0000

0x00040a58 0x0000:0000

0x00040a5c 0x0000:0000

0x00040a60 0x0000:0000

0x00040a64 0x0000:0000

0x00040a68 0x0000:0000

0x00040a6c 0x0000:0000

0x00040a70 0x0000:0000

0x00040a74 0x0000:0000

0x00040a78 0x0000:0000

0x00040a7c 0x0000:0000

RMcco · ‎02-22-2019

Hi SK -

One additional question: Registers 0x12 and 0x13 set the link timer value. According to the datasheet, the default value is 0x98968 - if those represent 8 ns ticks, that works out to 5 ms. But the datasheet says that the default is 10 ms. Is there an additional factor of two somewhere?

Also, the PHY we're using (TI DP83867) has four options for the SGMII link timer: 11 ms, 800 us, 2 us, and 16 ms. We're using the default, which is 2 us (which seems very short). This doesn't seem to be breaking auto-negotiation itself, but it's unclear if this also has an effect on the TSE declaring if/when the link goes down.

Thanks -

-Ryan

SengKok_L_Intel · ‎02-22-2019

Hi Ryan,

I don't think the link timer is a concern, if yes, then it should fail at first start the auto-negotiation. If there is a doubt, you may try to adjust it and see if any improvement.

Regards -SK Lim