C10GX and TSE with GXB transceivers

[GabrieleCoppolino]

Hi all,

I'm having some problems configuring the Triple Speed Ethernet core, working at 1Gbps, with a custom board with 6 transceiver channels (for now I'm trying to use 2 of them) connected to a Cyclone 10 GX. I have a system clock (125MHz) and a dedicated clock for transceiver bank (125MHz). I use Quartus Prime Pro 19.4 (with no license at the moment, which will result in a time-limited sof). My actual configuration is:

•    reset controller: configured as suggested for c10gx (70000ns of reset duration)
•    altera_xvcr_atx_pll_a10 OR altera_xcvr_fpll_a10 with transceiver mode: from gxb_clock 125MHz it generates a 1250MHz output frequency (2500Mbps of datarate). No MCBG, but I tried too.
•    Two TSE configured as 10/100/1000Mb Ethernet MAC with 1000BASE-X/SGMII PCS, transceiver type GXB, 32b of data width, SGMII bridge enabled into PCS options. pcs_ref_clk and rx_cdr_refclk are connected to gxb_clk

I am monitoring some signals from SignalTap: resets are good, pll locked and powerdown signals are ok too, and the most relevant thing is that, for both tse, led_connection_char_err and led_connection_disp_err are toggling a lot, while led_connection_link and led_connection_panel_link are down. Please find some screenshots attached.

Where could the problem be?

P.S. I'm able to use just the Native PHY at 1Gbps (one PHY per channel, whose outputs are shortcircuited-> i'm able to see the ethernet traffic from one side to the other, externally to the FPGA), but when I add the MAC (multirate LLE MAC should be much more simpler to use than PHY) it doesn't work. In addition I didnt' find a way to configure Native PHY with TSE configured as only MAC.

Thanks in advance

[CheePin_C_Intel]

Hi,

As I understand it, you are encountering some issue when using TSE with XCVR in C10GX devices. There seems to be no issue when you are using Native PHY only and performing loopback. However, when you hook up the TSE, you observe issue. For your information, I am currently engaging our TSE expert to provide further assistance. Thanks for your patience.

[GabrieleCoppolino]

Yes, exactly. Here attached the PHY configuration, where among two transceiver channels I shortcircuited rx_parallel_data and tx_parallel_data, and rx_datak with tx_datak.

[Deshi_Intel]

HI,

NativePHY IP won't have TSE preset configuration as it doesn't support customized MII, GMII, RGMII or SGMII interface to connect with TSE MAC. This unique feature is provided by TSE IP itself.

I can see that you are setting TSE IP with MAC + PHY serdes interface option.

• Your TSE IP error status signal indicate a lot of bit transfer error
• I suggest you checkout below example design to learn how to build and configure TSE IP solution

TSE IP support 2 types of serdes interface in Cyclone 10 GX FPGA (Either LVDS or transcevier)

For LVDS variance (when you select LVDS IO in TSE IP transceiver type). Checkout

• https://fpgacloud.intel.com/devstore/platform/15.0.0/Standard/arria-10-single-port-triple-speed-ethe...

For transceiver variance (when you select GXB in TSE IP transceiver type). This is closer to your original intent. Checkout

• https://fpgacloud.intel.com/devstore/platform/16.1.0/Standard/arria-10-triple-speed-ethernet-and-nat...

Thanks.

Regards,

dlim

[GabrieleCoppolino]

Hi dlim,

thanks for your reply.

I checked-out those projects which are a good source of informations.

However, I did not arrange a solution for me.

I'm able to connect two PHYs and see ethernet traffic in these situations:

• Basic/standard PCS with 8B/10B encoder and decoder enabled, shortcircuiting the two interfaces (the situation I wrote in the initial post)
• Basic/standard PCS with 8B/10B encoder and decoder disabled, shortcircuiting the two interfaces

In the second situation, PHYs have the 10bit tbi interface exposed. Disabling the transceiver option on the TSE, I got the same tbi interfaces (tx_d[9:0], rx_d[9:0], rx_clk, tx_clk). TSE is still configured 10/100/100 MAC + PCS with SGMII bridge enabled. This is the same configuration as in the second example you provided. Obviously the exposed TSEs avalon-ST interfaces have been shortcircuited, but it's not working.

In this situation tse_status_led_connection_link is high (but not the panel_link).

[Deshi_Intel]

Hi,

TSE IP itself already contains 8b/10b encoder/decoder so disable the 8b/10b encoder/decoder in NativePHY IP is correct way to go.

1. Earlier you mentioned about a lot of char_err and disp_err issue. Is this issue resolved ?
2. Now you mentioned obviously the exposed TSEs avalon-ST interfaces have been shortcircuited, but it's not working.

• Can you explain further what do you mean by Avalon-ST intreface is short circuit ? What is short circuit and why are they short circuit ?
  • Also can you elaborate further what's not working here ?

1. As for the panel_link doesn't assert high

• Panel_link has its own version of definition depends on the mode setting as indicated in TSE user guide doc (page 119, table 73)
  • https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_ethernet.pdf
  • But if panel_link stay zero highly indicate something wrong with Ethernet auto-negotiation (AN) process
  • Is your system setup trying to connect one TSE IP to another TSE IP ? If yes, then you need to configure one TSE IP into PHY mode AN while the other TSE IP into MAC mode AN
  • There are two auto-negotiation setting - PHY mode and MAC mode
  • 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.

Thanks.

Regards,

dlim

[GabrieleCoppolino]

Hi dlim,

>> 1. Earlier you mentioned about a lot of char_err and disp_err issue. Is this issue resolved ?

Now meantime I'm sending packets to the channel, led_connection_link is OFTEN high, until a led_connection_char_err (and consequently a led_connection_disp_err) occurs. Other led_connection_* signals are stable to '0', including led_connection_an (auto negotiation)

>>2.Now you mentioned obviously the exposed TSEs avalon-ST interfaces have been shortcircuited, but it's not working.

>> Can you explain further what do you mean by Avalon-ST intreface is short circuit ? What is short circuit and why are they short circuit ?

I used this therm improperly to indicate that:

tse0.tx <= tse1.rx

tse1.tx <= tse0.rx

where tse*.tx and tse*.rx are the avalon-st interfaces exposed by tse cores. Note that tse*.rx.ready and tse*.tx.ready are always '1'.

>>Is your system setup trying to connect one TSE IP to another TSE IP ? If yes, then you need to configure one TSE IP into PHY mode AN while the other TSE IP into MAC mode AN

My configuration is

......................................................FPGA

..................---------------------------------------------

pc1<-->| PHY0 <--> TSE0 <--> TSE1 <-->PHY1 | <-->pc2

.................|............... tbi...............a_st................tbi..............|

.................----------------------------------------------

note that i had to use dots instead of spaces

[Deshi_Intel]

Hi,

Ok, I get better understanding on your TSE system setup now. You are basically doing the loopback connection on Avalon ST side instead of external loopback on your board.

In this case, you can separate the debug effort in following sequence.

1. PC1 -> PHY0 -> TSE.Rx -> TSE0.Rx (avalon ST)

• I presume you still encounter intermittent error signal toggling where you may received wrong data at TSE0.Rx (avalon ST) ?
  • You should be focus on fixing this error first else wrong data will be loopback to TSE1.Tx later
  • Did you enable the TSE IP statistic counter setting to print out the report log ? Are we dealing with missing packet or just data error transfer ?
  • Would you be able to perform loopback on the PHY chip to isolate is this PHY chip issue or FPGA TSE IP issue ?
  • Have you tried switching the speed to 10M or 100M to see if the error signal still toggling ?
  • I am not sure how your PC1 design looks like. Are you using your own Ethernet application software at OS level or just some Ethernet tester equipment ? Have you reviewed your PC1 setting (auto-negotation, speed or full/half duplex setting) or your OS level Ethernet driver to ensure there is no buffer overflow issue that may corrupt data packet transfer.
  • Alternate option will be to switch to user other Ethernet packet generator. (For instance like using TSE1.Tx as source, then perform loopback on board to connect back to TSE0.Rx instead of using PC1 as source to isolate issue)

1. TSE0.Rx (avalon ST) to TSE1.Tx (avalon ST) to TSE.Tx to PHY1 to PC2

• Once RX side issue is resolved then you can elaborate what's the issue on Tx side or maybe everything should be good once Rx issue is resolved.

Thanks.

Regards,

dlim

[GabrieleCoppolino]

Hi dlim,

I inform you that the error was in the TSE software configuration (done by nios2 processor). Now it's working, thanks a lot for your replies.

[Deshi_Intel]

Hi,

Good to know issue is resolved at your side.

Alright, I will be setting this case to closure.

Hopefully everything goes well with your project development.

Thanks.

Regards,

dlim