phy: add a 10G PCS/PMA, with full PHY for US+ GTH and GTY transceivers

[storborg]

I just went to open this PR and noticed #217, which has some pretty similar work. Nice timing! I'll dig into the differences and see if I can adapt my PR to match that.

Summary

My goal was basically to make 10GBASE-R as turnkey and "native" as 1000BASE-X on UltraScale+.

• adds a 10GBASE-R PCS that also plugs onto LiteEth's XGMII frontend
• adds UltraScale+ GTY and GTH transceiver wrappers, based on the usp_gth_10g_baser.py file, but with some updates informed by the Vivado gt_wizard
• adds a complete wrapper PHY that packages up the PCS, PMA, and clocking to provide an interface that is essentially identical to the Xilinx 1000BASE-X PHYs
• adds an example testbench using the Alibaba KU3P board

I also used Alex Forencich's verilog-ethernet heavily for inspiration. My methodology was essentially to mirror the module architecture and interfaces, implement each module one at a time, and run equivalence checks between my blocks and Alex's. I deviated a bit from those equivalance checks in favor of compliance with 802.3ae, but in particular, kept Alex's watchdog strategy.

This branch is aggressively tested in simulation and in hardware on the Alibaba KU3P board, but not yet tested on a GTH platform (I am hoping to do this soon on the Tria AUBoard-15P). I'm primarily using Vivado 2026.1 and testing to X710 and ConnectX-5 NICs.

I'm marking this as a draft PR for a few reasons:

• I have not yet ported my tests into LiteEth, they are currently outside the repo.
• I'm not quite sure I have exposed the right conventions for loopback and PRBS testing. I'd like for the API to mirror other LiteEth PHYs.
• Most significantly: the addition of a 10G data path exposes a deadlock problem with Etherbone. The Etherbone core is (obviously) not capable of sustained transactions at the wire rate of 10G, but the PHY currently has no ability to backpressure. This results in individual words being dropped when the FIFOs are full, which can corrupt Etherbone packets, deadlocking the core. I would like to include a feature which adds opt-in packet-level dropping semantics on a crossbar port. This way, entire Etherbone transactions will be dropped (safe), instead of corrupting the packet. I think this is an important part of making 10G use simple and easy within LiteX.

TODO

• Add sim tests
• Document / streamline diagnostic control and status registers
• Add a patch that can improve Etherbone stability when connected to a 10G-capable crossbar I'll do this in a separate PR to try to keep them both easier to review

Future Work

• Investigate portability to 7-series GTX Maybe this is superseded by phy: add Artix-7 5GBASE-R support #217
• Investigate scalability to 25G: this seems really challenging on a 64-bit data path, but maybe work from Alex and others can provide some hints

[enjoy-digital]

Nice @storborg, funny timing yes with #217. I'll have a closer look soon (next week).

[storborg]

From reviewing #217, it ought to be practical to combine my work and yours to work at both 5G and 10G, on both 7-series GTP/GTX and US+ GTY/GTH.

Is it fair to assume that you would prefer the all-Python PCS rather than including the verilog-ethernet RTL?

I think I will try to:

1. Add the appropriate parameters to this branch to divide the clock rate, redo the GT Wizard, etc.
2. Update the Alibaba KU3P board testbench to run at 5G. Unfortunately, I think the only hardware I have to test this is one of those questionable copper SFP+ transceivers that theoretically works at 1/2.5/5/10. If anyone has any suggestions for 5GBASE-R native hardware, that would be really helpful!
3. Only then, work on the 7-series interfacing. Maybe it makes sense to extract out your 7-series synchronous gearbox interfacing from phy: add Artix-7 5GBASE-R support #217 into a separate module.

Side thought, it would be really cool to support auto-negotiation!

[jersey99]

@storborg This looks good!

I have been using the GT{X/Y/H} transceivers in the 64b66b route for several protocols, most importantly for 10G, Aurora and some other custom protocols, similar to what you have done here mixed in with Forencich's Block Sync and LFSR code. My one recommendation would be to keep 64bit transceiver instantiation re-usable. And bonus points would be if the GT code is reconciled with the standard 20-40 bit liteiclink stuff.

But this is good work, thank you!

@enjoy-digital I will test this on another one of my boards to give you some more confidence if you need it.

[storborg]

Thanks @jersey99! Your LiteEth repo was one of the few resources I could find on getting 10G operational in LiteX at all, very helpful starting point.

Maybe it makes sense for the transceiver instantiations to be maintained in liteiclink instead of here?

Reconciling them with the 20-40 bit liteiclink code seems difficult, and I'm not really sure what that would entail. Do you mean using the same module classes with parameter options for the data format? Or just mirroring the interface pattern?

[storborg]

Ok, I've added a 5GBASE-R UltraScale+ implementation to this branch, and wired it into the same Alibaba KU3P testbed. It's not stress-tested yet, but it works in PMA loopback modes, and brings up a link with another 5GBASE-R device:

5GBASE-R <-> 88X3310 PHY <-> 5GBASE-T <-> AQC111U USB 3.1 interface

Thanks to the PCS being identical, this was mostly just a matter of working the gt_wizard output differences into the transceiver instantiation classes.

However, actually testing against a real hardware peer was a weird side quest into SFP+ transceiver internals! See comment here.