Help with 10G Ethernet Configuration

[JShel4]

Newbie question on 10G Ethernet configuration.

I have Arria 10 FPGA sitting between the SFP+ optical module and 10G backplane connector (i.e. SFP+ --> FPGA --> backplane).

What is the easiest way for me to create a pass through path for the Ethernet packets?

[ I do not want to look at the packets inside the FPGA. I just want to pass them to the CPU via the backplane connector]

Thank You in advance to anyone who has ideas and is willing to help!

[Deshi_Intel]

Hi JShel4,

If you don't care about MAC functionality and processing then you can just use Arria 10 FPGA Ethernet PHY IP like "1G/10GbE and 10GBASE-KR PHY" IP to intercept your incoming data traffic from SFP module and retransmit the XGMII data to another Ethernet PHY IP and then blast out to your backplane.

KR option is available to support feature like "auto negotiation" and "link-training" in case you need it.

Thanks.

Regards,

dlim

[JShel4]

Hello dlim, thank you for the quick response. I think I understood your point. Please help verify my implementation:

I am attaching two pictures towards the end of this reply --- showing the data paths --- XGMII (for 10G) and GMII (for 1G).

Logically, my Ethernet PHYs look something like this: SFP+ --> 1G/10G Phy --> KR PHY --> Backplane connector

• Line PHY == SFP+ to A10 1G/10G PHY
• KR PHY == A10 KR PHY to Backplane connector

Question: Do you see any issues in the data path - especially for XGMII ... do I need to re-wire for SDR XGMII? (like the table shown in page 137 of the Transceiver User Guide)?

One more question: Any suggestion on how to close timing inside the KR IP? I see timing violations in and around the AN block. For e.g. :

From Node: phys|kr_phy|xcvr_10gkr_a10_0|CHANNEL|rx_parallel_data_native[26] To Node: phys|kr_phy|xcvr_10gkr_a10_0|CHANNEL|AN_GEN.AUTO_NEG|DECODE|dme_dly2[26]   Launch Clock: phys|kr_phy|xcvr_10gkr_a10_0|rx_pma_div_clk Latch Clock: phys|kr_phy|xcvr_10gkr_a10_0|rx_pma_div_clk   Data Arrival Time: 15.434 Data Required Time: 13.897   Slack -1.537 (VIOLATED)

Screen Shots of the GMII and XGMII data paths between the two PHYs

[Deshi_Intel]

Hi JShel4,

It's fine to connect xgmii_rx_dc to xgmii_tx_dc. It should be able to recognize as both are Intel FPGA IP. The XCVR PHY user guide doc explanation is meant for connection to 3rd party IP that use xgmii_sdr_data/ctrl interface.

Can you traced the timing failure path is really constrained within KR PHY IP only. Then this is expected known issue that can be ignored as mentioned in XCVR PHY user guide doc. Refer to attached pic.

However, my recommendation is to always use latest Quartus version (for instance v18.1) to compile your design so that it contains all the latest issue bug fix.

Thanks.

Regards,

dlim

[JShel4]

Thanks Dlim! I am using version 18.1 Pro on Linux. It seems that Intel/Altera IP is not fully battle tested. I also see Big timing violations when using the clocking scheme recommended in the PHY user guide and AN795 - specifically when getting XGMII clock from separate FPLL to clock the registers interfacing with the XGMII tx and rx paths of the 1g/10g phy.

One question: Does the 1G/10G PHY auto down-train from 10G to 1G? I am seeing the following behavior in my bring-up. Please let me know if you have any thoughts on this:

1. The 1G/10G PHY (not KR), establishes the link successfully when connected to a Netgear 1G switch - using a SFP+ cable
2. However, it does not link - up when connecting to a 10G Netgear switch using the SFP+ cable. In this case, the lock-to-data never stays high - it keeps toggling or loosing the lock.

Please let me know what you think. Appreciate all your thoughts/help!

[Deshi_Intel]

Hi JShel4,

Yes, it will auto down trained from 10G to 1G if link can't maintain at 10G.

I presume you are referring to CDR loose lock condition when you mentioned lock_to_data is toggling. This normally is caused by signal integrity concern.

You can refer to attached debug checklist to get some clue on where to debug. Although this debug checklist is created for Cyclone 10 FPGA but the debug flow is the same.

Thanks.

Regards,

dlim