UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Explorer
Explorer
4,471 Views
Registered: ‎04-19-2016

1G/2.5G PCS/PMA or SGMII v16.0 IP generates idle packets

Jump to solution

Hello , 

 

I am using 1G/2.5G PCS/PMA or SGMII v16.0 IP  in a mode of SGMII over LVDS in Zynq. I think that IP does not generate the correct packets. I have read the status_vector[15:0] of the IP such an 0x000B. So what does it mean? I have read the Table 2-41 in the  pg047-gig-eth-pcs-pma document  in page 64. So, does it mean that GMII interface does not send valid data to IP? so IP keep in the its idles state. Why IP keep its idle state? 

 

Thank you.

Tags (4)
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Moderator
Moderator
7,205 Views
Registered: ‎08-25-2009

Re: 1G/2.5G PCS/PMA or SGMII v16.0 IP generates idle packets

Jump to solution

Hi,

 

The IP itself does not generate packets. What is your link partner? The status vector seems to show a link and synchronization up; but it's receiving idle ordered sets. What is connecting on the other side of the link? What does it send to Zynq? Are you connecting this core to Zynq GEM or TEMAC on PL?

"Don't forget to reply, kudo and accept as solution."
0 Kudos
10 Replies
Highlighted
Moderator
Moderator
7,206 Views
Registered: ‎08-25-2009

Re: 1G/2.5G PCS/PMA or SGMII v16.0 IP generates idle packets

Jump to solution

Hi,

 

The IP itself does not generate packets. What is your link partner? The status vector seems to show a link and synchronization up; but it's receiving idle ordered sets. What is connecting on the other side of the link? What does it send to Zynq? Are you connecting this core to Zynq GEM or TEMAC on PL?

"Don't forget to reply, kudo and accept as solution."
0 Kudos
Explorer
Explorer
4,442 Views
Registered: ‎04-19-2016

Re: 1G/2.5G PCS/PMA or SGMII v16.0 IP generates idle packets

Jump to solution

Hello ,

 

  • The 1G/2.5G PCS/PMA or SGMII v16.0 IP core is connected to a Zynq GEM. 
  • There is a pair of LVDS link between two Zynq SoCs located the same custom design board.
  • There is no PHY IC on the link.
  • So link partner is directly another 1G/2.5G PCS/PMA or SGMII v16.0 IP  in other Zynq. 
  • I try to communicate two SoCs' GEM over SGMII LVDS. 
  • We have a custom TCP/IP stack on application side and we are sending UDP packets to IP. 
  • But there is currently no communication between two SoCs GEM. IP everytime gives idle characters in its output. 

Thank you.

0 Kudos
Moderator
Moderator
4,411 Views
Registered: ‎08-25-2009

Re: 1G/2.5G PCS/PMA or SGMII v16.0 IP generates idle packets

Jump to solution
Have you checked if the packets are coming out from the GMII interface from one side? Have you captured GMII interface with gmii_txd to verify it's a valid packet? This is the first thing to check. If you've receiving idle on one side, it's most likely the link partner is sending idle too.
"Don't forget to reply, kudo and accept as solution."
0 Kudos
Explorer
Explorer
4,402 Views
Registered: ‎04-19-2016

Re: 1G/2.5G PCS/PMA or SGMII v16.0 IP generates idle packets

Jump to solution

Hello ,

 

  • I have checked the GMII interface (gmii_txd[7:0], gmii_tx_en, gmii_tx_er nets were observed, as seen sgmii_chipscoped_nets.png file attached, you can see debugged nets) coming to IP by inserting ILA core in design. 
  • I have triggered on the gmii_tx_en net in ILA core.
  • When we run the 'data send' command in the SW in (TCP/IP app), ILA captured a waveform as seen attached file (sgmii_tx_enab_and_data.png)
    • gmii_tx_en = GMII interface tx enable signal coming from zynq ethernet controller. it is seen as tutorial_i/gig_ethernet_...block_i/sgmii_logic_n_2 in ILA core. 
    • gmii_tx_er =  GMII interface tx error signal. It is seen as tutorial_i/gig_ethernet_...block_i/sgmii_logic_n_3 in ILA core. 
    • gmii_txd[7:0] = GMII interface tx error signal. It is seen as corresponding nets name tutorial_i/gig_ethernet_...block_i/sgmii_logic_n_6...13 in ILA core.  (Note that 8-bit) 
    • txdata[7:0]     = This signal go to LVDS sgmii output which is 8-bit. And input to the 8B/10B encoding block. tutorial_i/gig_ethernet_...pma_block_i/txdata[7:0] ( Note that idle pattern here)
    • DOUT[9:0] =  This signal is 10-bit output signal of 8B/10B encoding block. It is seen as tutorial_i/gig_ethernet_...ransceiver_mw/DOUT[9:0](you can see the idle pattern again) 
    • We run the data send command in software and then capture the those signals. We interpreted the changing in the lines gmii_txd[7:0] (tutorial_i/gig_ethernet_...block_i/sgmii_logic_n_6...13 ) as ARP packet request that we sent and ARP packet is 60 Bytes. We have changed data we sent but observed waveform did not change. We have changed the IP address of target link partner(second SoC) and send again, only 16-bit portion of waveform is changed as usual. So this observation is ARP packet request. 
    • I think that problem is here, first SoC broadcasting ARP request, but this ARP request does not reach to second SoC because its RX buffer is empty. For this reason second SoC will not send ARP Reply due it did not take ant ARP Request. Therefore any ARP reply did not reach to first SoC, so first SoC does not send DATA. So we read IP status all time 0x000B. 
    • Does not this 1G/2.5G PCS/PMA or SGMII v16.0 IP support ARP Request/Reply manner mechanisgm in SGMII over LVDS case? Why ARP request does not reach to second SoC in this case?
    • In fact, in our application , ARP request/reply is really necessary? Because there is only two link partners( first SoC and Second SoC, point-to-point connection.  no any device.)  

Regards,

Tags (4)
sgmii_chipscoped_nets.PNG
sgmii_tx_enab_and_data.png
0 Kudos
Xilinx Employee
Xilinx Employee
4,358 Views
Registered: ‎02-06-2013

Re: 1G/2.5G PCS/PMA or SGMII v16.0 IP generates idle packets

Jump to solution

 

Hi

 

It looks you have not added GMII data and control signals to the ILA.

 

However if you are able to see the data changing the GMII but the output of the core is idle's always then I suspect the isolate bit is not set to normal mode.

 

IEEE 802.3-2008 clause 22.2.4.1.6 states that by default, a PHY should power up in an isolate

state (electrically isolated from the GMII).

• If you are using the core with the optional management interface, it is necessary to

write to the PCS Configuration Register 0 bit 10 to 0 to take the core out of the isolate state.

• If using the core without the optional management interface, it is the responsibility of

the client to ensure that the isolate input signal in the configuration_vector bit 3 is

asserted at power-on and set to 0 for normal operation.

 

Regards,

Satish

--------------------------------------------------​--------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful.
--------------------------------------------------​-------------------------------------------
0 Kudos
Explorer
Explorer
4,252 Views
Registered: ‎04-19-2016

Re: 1G/2.5G PCS/PMA or SGMII v16.0 IP generates idle packets

Jump to solution

Hello @yenigal@nanz

 

  • We drives as '0' the isolate bit 10 in MDIO Control register as you suggest me.

You can see the chipscope waveform as .zip file taking by TCL command 

 

write_hw_ila_data my_hw_ila_data_file.zip [upload_hw_ila_data hw_ila_1], attached. 

 

  • I think these on the gmii_txd lines are ARP packet. 
  • Please note that we read IP status_vector as 0x00B0, so duplex mode and speed selection is incorrect(It should be full duplex and 1Gb/s). May not we configure the IP correctly via MDIO interface? How can be sure that I am correctly write/read to/from IP via MDIO interface?
  • We wrote (Speed Selection (LSB )= 10, Speed Selection (MSB)=10 and Duplex Mode=1, all other 0) to MDIO Control Register in page 45 of pg047-gig-eth-pcs-pma.pdf and read Status Register as all 16-bit are '1',  in page 48 of same document. Do we write/read correct values, what do you think? MDIO interface works correctly? 

Best Regards,

Thank you.

Tags (4)
0 Kudos
Explorer
Explorer
3,840 Views
Registered: ‎11-28-2011

Re: 1G/2.5G PCS/PMA or SGMII v16.0 IP generates idle packets

Jump to solution

Having the same issue with version 16.1 of the core. Any resolution on this?

0 Kudos
Explorer
Explorer
3,828 Views
Registered: ‎04-19-2016

Re: 1G/2.5G PCS/PMA or SGMII v16.0 IP generates idle packets

Jump to solution
Hello @polyee13,

Please check the Zynq GEM registers. EMIO should be selected as source of receive clock, data and control signals as seen below. Basicly our problem was this. Below registers were still, wrongly, selected as MIO. But they should be EMIO due to you use ethernet from FPGA side.

• To select the EMIO as the source of receive clock, data, and control signals: Set SLCR.GEM1_RCLK_CTRL[SRCSEL] bit to 1
• To select the EMIO as the source to generate reference clock: Set SLCR.GEM1_CLK_CTRL[SRCSEL] bit to 3’b1xx
where ‘x’ is don’t care (can be either 1 or 0)

And also you can check app note XAPP1082.

Best regards,
0 Kudos
Explorer
Explorer
3,825 Views
Registered: ‎11-28-2011

Re: 1G/2.5G PCS/PMA or SGMII v16.0 IP generates idle packets

Jump to solution
I think we might have an issue with the MDIO interface itself. Did you have any issues with it initially?
0 Kudos
Explorer
Explorer
1,642 Views
Registered: ‎04-19-2016

Re: 1G/2.5G PCS/PMA or SGMII v16.0 IP generates idle packets

Jump to solution
No. MDIO interface worked properly. We have also read status vector of IP. All problem was IP generates idle pattern. But this is a normal and expected reaction from IP, if there is no data on the GMII interface as written in IEEE 802.3. Please be sure that MDIO is ticked in Zynq configuration, and EMIO is selected as source and MDIO ports of Zynq and MDIO ports of IP is properly connected to each other.
0 Kudos