Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Work-in-progress] An applet for communicating using an Ethernet RGMII PHY #562

Draft
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

whitequark
Copy link
Member

@whitequark whitequark commented Apr 20, 2024

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)
  • 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

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 :)

@whitequark whitequark marked this pull request as draft April 20, 2024 04:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants