RX Mac segmented interface detailed information

Hi Ankit,

What you are seeing is actually consistent with a 60-byte ARP frame on the F-Tile 400G RX MAC segmented client interface.

At 400G, o_rx_mac_data[1023:0] is divided into 16 segments, and each segment is 64 bits = 8 bytes. The inframe[15:0] bus gives one bit per 8-byte segment, and o_rx_mac_eop_empty[47:0] provides the empty-byte count for the segment where the packet ends. The documentation also says packets may start on any 8-byte segment, and SOP/EOP are inferred from inframe transitions between adjacent segments and cycles.

In your Signal Tap capture, the inframe values are E000h and 000Fh. That means there are 7 segments total with inframe=1, which corresponds to 7 × 8 = 56 bytes of fully occupied segments.

The remaining 4 bytes come from the EOP segment. This is exactly what o_rx_mac_eop_empty is for. On the last segment of the packet, the empty-byte field tells you how many bytes in that 8-byte segment are unused, counting from the most significant byte side. So if the EOP segment has 4 empty bytes, then only 4 bytes in that final 8-byte segment are valid. Total frame length is therefore:

• 56 + (8 - 4) = 60 bytes.

So the key point is that inframe by itself only tells you which 8-byte segments belong to the frame. It does not by itself give the exact frame length when the last segment is only partially used. You must combine inframe with eop_empty to get the final byte count.

For SOP and EOP detection, the interface is typically interpreted as follows:

• SOP is the first 0 -> 1 transition in inframe when scanning segments in order, including the boundary from the previous cycle.
• EOP is the first 1 -> 0 transition in inframe when scanning segments in order.
• The segment just before that 1 -> 0 transition is the ending segment, and its corresponding eop_empty field tells you how many bytes of that final segment are unused.

For 400G specifically, note that o_rx_mac_eop_empty[47:0] is not a single number for the whole bus. It is 16 separate 3-bit fields, one per 8-byte segment. You need to look at the 3-bit field corresponding to the segment where EOP occurs.

A practical way to calculate the received frame length is:

• count 8 bytes for every full inframe=1 segment before EOP
• identify the EOP segment from the 1 -> 0 transition
• read that segment’s eop_empty value
• add 8 - eop_empty bytes for the last segment

Using that method, your captured ARP request decodes cleanly as a 60-byte Ethernet frame, which matches what you are seeing in Wireshark.

So in short: there is no missing 4-byte discrepancy. Those 4 bytes are the valid part of the final segment, and eop_empty is the signal that tells you that.

Regards,

Pavee