Community
cancel
Showing results for 
Search instead for 
Did you mean: 
MRigh4
Beginner
182 Views

TSE SGMII autonegotiation fails and link goes down after ethernet cable connection

Hello,

I instantiated the variation "10/100/1000Mb Ethernet MAC with 1000BASE-X/SGMII PCS" IP variation of the Triple-Speed Ethernet Intel IP core. 

I configured the PCS registers as suggested in the user guide:

LINK_TIMER_MSW : x"00000D40"
LINK_TIMER_LSW : x"00000003" -> to get 1.6ms link timer required by SGMII
PCS_IF_MODE : x"00000003" -> SGMII_ENA = 1; USE_SGMII_AN = 1
PCS_CTRL_REG : x"00001140" -> AUTO_NEGOTIATION_
ENABLE = 1; DUPLEX_MODE = 1
PCS_CTRL_REG : x"00009140" -> to reset PCS (after this I repeatedly read the register to check that the reset bit has been cleared)

After reset, before connecting an ethernet cable to a PC, I have the following acquisition from SignalTap:

 

Signal Tap acquisition before connecting the cableSignal Tap acquisition before connecting the cable

led_an and led_link are high, therefore I assume that the PCS was able to complete the autonegotiation with the PHY. 

After connecting a ethernet cable, I have the following behaviour:

led_an goes low, led_link goes low. I catch those events and reset the PHY (is a TI DP83867IS) writing in its CTRL register. After that, the PCS tries again an autonegotiation, but soon it fails again an I repeat the procedure. The result is that I can't recover the situation. 

Signal Tap acquisition after cable connectionSignal Tap acquisition after cable connection

My questions are:

1. Is there something that I set wrong in PCS registers?

2. Do I also have to set something in the PHY?

3. Why autonegotiation between PHY and PCS is affected by external cable connection? What do i miss??

Thank you,

Marco

0 Kudos
4 Replies
Deshi_Intel
Moderator
169 Views

Hi Marco,


As you are facing system level failure, hence it's hard to tell which path went wrong in the first place.

  • Is it FPGA design ? On board PHY chip configuration ? your board setup issue ? or the destination Ethernet port or equipment issue


May I suggest you start with something simple to slowly isolate the failure


Thanks.


Regards,

dlim



MRigh4
Beginner
165 Views

Thank you for the answer dlim.

It is a FPGA design, completely HW based, without NIOS processor. VHDL FSMs configure both the PHY and the TSE. 

Actually it seems to be a system level issue. I tried to understand this behaviour for a week without success. During all my tries, for some reasons I also tried to connect the board to another ethernet device (is the USB docking station of the PC, with a ethernet interface) and it seems that the autonegotiation issue is not present here. I can transfer packets from PC to FPGA and viceversa. 

Now I think that the problem is relevant the autonegotiation phase between the TI PHY and the external device... and not relevant the configuration of the TSE so I don't think that a simulation of the TSE would help but I'm still trying to figure out a solution.

If you have other suggestion, I will appreciated it. 

Thank you,

Marco.

Deshi_Intel
Moderator
154 Views

HI Marco,


I see. So, you have further isolated the issue to be within Ti PHY and external device.


Common Ethernet setting that you should watch out is like below

  • Speed - 1G, 100M, 10M
  • Full duplex vs half duplex
  • Autonegotiation on/off


Below is good article that talks about common factor with autonegotiation failure


As for TSE IP autonegotiation setting, you want to watch out for PHY mode vs MAC mode setting

  • PHY mode = the speed and duplex mode of our FPGA and external device will be resolved based on the value set in the dev_ability register. Meaning PHY mode is for advertise the link speed and duplex mode to the link partner


  • MAC mode is wait for the link speed and duplex mode from link partner and then resolve based on the link_partner ability register.
  • One side should be set as PHY mode and the other side should be set as MAC mode


Thanks.


Regards,

dlim



Deshi_Intel
Moderator
136 Views

HI,


I have not hear back from you for a while.


Hopefully my earlier feedback is useful for u


For now, I am setting this case to closure.


Thanks.


Regards,

dlim


Reply