[WIP] An applet for communicating using an Ethernet RMII/RGMII PHY

[whitequark]

Remaining work before I'm willing to un-draft this, in no particular order:

• put the very (almost but not quite excessively) clever IODelay into its own module
• make RX/TX IO delay configurable (it's PHY-dependent)
• extract OUT-FIFO -> TX-PACKET and IN-FIFO <- RX-PACKET state machines into their own components
• write documentation (applet description)
• add IEEE 802.3 standard to the Glasgow archive
• extract most of the host-side Python logic into an EthernetInterface class (doesn't have to be EthernetRGMIIInterface since it's not RGMII-specific)
• make statistics display and period configurable
• make host-side code more zero-copy than it is now (and drop writev) good enough
• alternatively, drop writev but integrate its functionality into write itself (this is questionable because it's really not clear how the read counterpart should work, and in any case it seems like complicating the API for no good reason; this applet really should be using zero-copy read_into and write_into but adding those is actually quite challenging no really it's good enough

To be clear, this is already an excellent MAC that easily meets or exceeds specifications of some commercial USB NICs, especially when it comes to performance under load. You can spam it with hundreds of megabits or even gigabits of UDP junk and the latency never gets above 20 ms on my laptop, usually it's under 2 ms. You can play real-time games or use ssh during that. I just have brainworms and want it to be perfect.

Things that will not get done in this PR:

• support for jumbo frames (requires the Ram-Pak addon and a very complex engineering project implementing a HyperRAM FIFO, since there's not enough BRAM)
• 1GBASE-T support. it is feasible (the fast domain is already constrained for 125 MHz and is architected for posedge-posedge arcs) but requires Amaranth 0.5 first
• fairness for the FX2 crossbar (difficult, incredibly finicky, and is liable to break other applets)
• automatic interface bringup via RTNETLINK (have you seen RTNETLINK? I hate myself but not this much)
• Windows and macOS support (patches welcome)

See, I'm able to limit the scope :) Slightly :)

The most significant out-of-scope issues are probably 1GBASE-T support (which is relatively easy to fix and is an appealing fix because it verifies some Amaranth code) and fairness for the FX2 bus (which absolutely tanks performance if you do bidirectional spam at 100M bandwidth... which is also why I didn't post that particular benchmark :)

[TomKeddie]

@whitequark am thinking to build a PCB to adapt the SZFPGA board onto Glasgow. At some point this can become a addon with the PHY on board.

I see these pins, I guess you're white-wiring them to Glasgow. Would you be able to share the pinout you're using so I can match it? We could then add them as defaults in the code.

access.add_pin_argument(parser, "rx_clk", default=True, required=True)
access.add_pin_argument(parser, "rx_ctl", default=True, required=True)
access.add_pin_set_argument(parser, "rx_data", 4, default=True, required=True)
access.add_pin_argument(parser, "tx_clk", default=True, required=True)
access.add_pin_argument(parser, "tx_ctl", default=True, required=True)
access.add_pin_set_argument(parser, "tx_data", 4, default=True, required=True)

I will wire the MDIO, reset and clock out to the remaining 4 pins.

[whitequark]

I've updated the applet for modern Glasgow, although haven't yet brought it up to speed to modern Amaranth. That is pending.

@TomKeddie The pinout is visible if you do glasgow run applet --help:

  --rx-clk PIN        bind the applet I/O line 'rx_clk' to PIN (default: A0)
  --rx-ctl PIN        bind the applet I/O line 'rx_ctl' to PIN (default: A1)
  --rx-data PINS      bind the applet I/O lines 'rx_data' to PINS (default: A2,A3,A4,A5)
  --tx-clk PIN        bind the applet I/O line 'tx_clk' to PIN (default: A6)
  --tx-ctl PIN        bind the applet I/O line 'tx_ctl' to PIN (default: A7)
  --tx-data PINS      bind the applet I/O lines 'tx_data' to PINS (default: B0,B1,B2,B3)

I am quite interested in such a board, by the way!

[whitequark]

Updated to add RMII support. The new common Ethernet code isn't as high-performant as the old RGMII-only code, this is being investigated.

[whitequark]

Remaining work:

• Attempt a 1GBASE-T function for RGMII
• Do something about statistics (either decide to ditch it, or figure out how to include it; big counters at 125 MHz may prove problematic, as will their atomic capture)