sim/ethernet: handle both GMII and bare frames on TX for tap0#2470
Open
theox33 wants to merge 1 commit into
Open
sim/ethernet: handle both GMII and bare frames on TX for tap0#2470theox33 wants to merge 1 commit into
theox33 wants to merge 1 commit into
Conversation
The ethernet simulation module previously wrote the raw TX byte stream directly to the TAP interface. When used with LiteEthMAC, the stream includes a 7-byte preamble (0x55), an SFD byte (0xd5), and a 4-byte FCS. Because TAP interfaces expect bare Ethernet frames, this shifted the payload by 8 bytes, producing malformed headers (e.g., ethertype 0xffff) that the host kernel dropped. Conversely, when used with Etherbone (with_preamble_crc=False), frames are already bare and were handled correctly. This commit updates the TX path in `ethernet_tick()` to dynamically handle both cases: - If a preamble and SFD are detected, they are stripped, and the trailing 4-byte FCS is removed before calling tapcfg_write(). - If no preamble is detected (e.g., Etherbone), the frame is assumed to be bare and is passed through verbatim without stripping an FCS.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
sim/ethernet: strip GMII preamble and FCS before writing to tap0
Problem
The
ethernet_tick()function inlitex/build/sim/core/modules/ethernet.caccumulates every byte emitted on thesourcesignals and writes them verbatim to the TAP interface viatapcfg_write().This causes an issue depending on the module connected to the PHY:
0x55, 1 byte SFD0xd5, the Ethernet frame, and a 4 bytes FCS). Writing this full stream shifts the frame by 8 bytes on the TAP interface. This produces corrupted Ethernet headers that the Linux kernel silently discards.with_preamble_crc = FalseinLiteEthPHYModel) outputs bare frames without preamble or FCS, which works perfectly with the current code.Observed symptom on tap0 with LiteEthMAC (tcpdump):
55:d5:ff:ff:ff:ff > 55:55:55:55:55:55, ethertype Unknown (0xffff), length 72The ARP/ICMP payload was present and correct at a +8 byte offset, but the malformed header prevented any host↔SoC communication.
Fix
This PR introduces a lightweight state machine in the TX path of
ethernet_tick()to dynamically support both use cases:0xd5). It starts accumulating only from the following byte (first byte of dst MAC) and flags the frame to strip the last 4 bytes (FCS) before callingtapcfg_write().The RX path (tap0 → SoC) remains unchanged.
Testing
Verified in Verilator simulation with
LiteEthPHYModelon a TAP interface (tap0):LiteEthMAC(192.168.1.50) andEtherbone(192.168.1.51) can coexist and operate correctly.pingfrom host to both IP addresses returns 5/5 replies.tcpdump -i tap0shows correct ARP request/reply exchanges followed by valid ICMP echo requests/replies, with no0xffffethertype corruption.