Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎01-15-2019

gig_ethernet_pcs_pma fails to complete autonegotiation when adding more logic to the PL


I'm trying to establish an ethernet connection using the ZynQ Ultrascale+ GEM0 via EMIO and a gig_ethernet_pcs_pma IP core. Unfortunately, Autonegotiation fails in some constellations:

  • Earlier in the project, everything was working very stably.
  • Then, I added some things to the PL. Now auto negotiation failed. I routed some clock outputs of the IP core to pins to check if the clocks were okay. With this modification, autonegotiation worked again. I found out that the reference clock input pin had a wrong frequency setting. I changed this and optimized something in the remaining PL logic --> It worked again.
  • I added more stuff to the PL. Again, it stopped working. I started to analyze the Phy status vector and so on. Things didn't make much sense, so I started searching the internet for other users' problems with the IP core and found that Vivado 2019.1 which I am using doesn't automatically add the timing constraints for the MDC clock. I added them and everything worked again.
  • I added more stuff to the PL. Sadly, it stopped working again. And I am out of ideas. Could you please help? I still think it's probably something about missing timing constraints or incorrect intialization logic that leads to the system failing sometimes (and sometimes not).
  • When I change to a bitfile that worked previously, the newest software I'm running works also. So working or not working seems to depend on the PL part.

I will try to describe what I have in Hardware:

  • XCZU6EG-FFVC900-1-i
  • gig_ethernet_pcs_pma IP with transceiver at X1Y12
    • 62.499374 MHz DRP clock frequency coming from the PS's PL clock 2.
    • Rx Gmii Clk Src: RXOUTCLK
    • Auto negotiation enabled
    • Shared logic included in core
    • Input connections:
      • mdio_pcs_pma connected to EMIO, GEM0
      • gmii_gem_pcs_pma connected to EMIO, GEM0
      • gtrefclk_in connected to a Si5344, 125 MHz. Some other outputs of the Si5344 are working fine even when the ethernet is not. So I'm quite sure clock generation is ok.
      • independent_clk_bufg connected to PS PL clock 2 at 62.499374 MHz
      • phyaddr bound to 0x11
      • configuration_vector bound to 0
      • configuration_valid bound to 0
      • an_adv_config_vector bound to 0
      • an_adv_config_val bound to 0
      • an_restart_config bound to 0
      • reset is '1', when the PS's pl_resetn_0 = '0' or when I assign a reset using a AxiGpio clocked with 100 MHz (problem? do I need to synchronize it??)
      • signal_detect is one when the SFP loss of signal is '0'. I can force it to zero using the same AxiGpio core I mentioned above.
    • Output connections:
      • SFP: connected to an optical SFP module. Should be fine since it worked great before.
      • clock outputs: not connected. Connecting them to certain I/O pins sometimes helps as described above. However, I would not like to do that, doesn't sound like a good solution...
      • the rest of the outputs are connected to another AxiGpio clocked at 100 MHz for monitoring.
  • Constraints:
    • create_clock -period 400.00 -name mdio_mds_clock [get_pins xu1_srio_i/zynq_ultra_ps_e_0/inst/PS8_i/EMIOENET0MDIOMDC]
    • create_clock -period 16.000 -name clk62 -waveform {0.000 8.000} -add [get_nets xu1_srio_i/zynq_ultra_ps_e_0/pl_clk2]
    • create_clock -period 8.000 -name eth_refclk -waveform {0.000 4.000} -add [get_ports EthClk_clk_p]

I do not get any timing errors during hardware compilation. Also, the timing wizard does not propose any more constraints for the ethernet system or adjacent areas.


Software reset process:

  • Upon software startup, the signal detect is asserted, the reset is not asserted.
  • I program the Si5344
  • I reset the IP core, wait for 10 ms, deassert the reset, wait for 10 ms
  • I enable the SFP module's TX, wait for 10 ms
  • I force signal detect low, wait for 10 ms, allow it to go high to reset the connection
  • I run lwip_init as part of the FreeRtos I'm using (tick rate is at 1kHz)
  • The problem occurs in xemacpsif_physpeed.c, get_IEEE_phy_speed. The Phy does not complete autonegotiation.
  • I added code there to reset the phy again if autonegotiation does not complete after a couple seconds, but it doesn't help. Also restarting the autonegotation doesn't help.
  • I can read the following hardware status:
    • MMCM lock: 1
    • Pma Reset: 0
    • Gt power good: 1
    • Isolate: 0
    • phy reset done: 1
    • Status vector: 0x0806 (1000Mb/s, RUDI(/C/) (receiving /C/ ordered auto-negotiation sequences), Link synchronization obtained)
  • I can read the following software status:
    • Phy Control register (Offset 0): 0x1140
    • Phy Status register (Offset 1): 0x01C8
    • Phy Advertising register (Offset 4): 0x01A0
    • Phy Partner register (Offset 5): 0x0000 (this should be different!!)
    • GEM Network Control register (Offset 0): 0x0010
    • GEM Network Config register (Offset 4): 0x012F2CC3 (I changed this, adjusting the MDC clock frequency to a defined value, that field was 0b111 before which is undefined... Sadly, didn't help.)
    • Gem Network Status register (Offset 8): 0x06
    • PCS Control register (Offset 0x200): 0x1140
    • PCS Status register (Offset 0x204): 0x0109

I hope I listed everything that might give an hint... Any advice would be much appreciated, I am running out of ideas. What am I doing wrong / missing here?

Thank you so much!

0 Kudos
1 Reply
Registered: ‎08-25-2009

Hi @lbaruschka_sie ,

I would like to check first if the design is completely timing clean. When you add logic to it, the ethernet link is broken. SO this leads me to think it may be a timing related issues.

I'd also try to lock your ethernet part of the design in a pblock or so so that part is not impacted by the rest the design to see if that helps.


"Don't forget to reply, kudo and accept as solution."
0 Kudos