RX Mac segmented interface detailed information

1. Your four basic scenarios (single SOP, single EOP, both, or neither)

Yes, all four of your scenarios are valid. The F-Tile Ethernet Hard IP RX client interface allows the application to read frame data from the RX MAC segmented when it is received, and packets may start on any 8-byte segment. RX MAC Segmented Client Interface The inframe signal encodes SOP/EOP transitions per segment, so any combination of those four cases can appear in a given cycle.

2. Can there be 2 or more SOPs or 2 or more EOPs in a single cycle?

Yes,

At 400GE you have a 1024-bit (128-byte) data bus with 16 inframe bits, where each segment is 64 bits (8 bytes). RX MAC Segmented Client Interface A minimum-size Ethernet frame (e.g. ARP) is 60 bytes = 7.5 segments, so it fits comfortably within one 128-byte cycle. That means in a single cycle with o_rx_mac_valid=1 you can have:

Two or more complete frames (each with its own SOP and EOP transition in the inframe vector)

Two or more SOPs (start of multiple frames)

Two or more EOPs (end of multiple frames)

For multi-segmented interfaces, a new packet may start and the previous packet end within the same cycle. RX MAC Segmented Client Interface At 400G with 16 segments per cycle, this can happen multiple times in the same clock.

3. How SOP and EOP are encoded in o_rx_mac_inframe[15:0]

The o_rx_mac_inframe transition from 0→1 (between two consecutive segments) indicates a start of packet (SOP); the SOP begins at the segment where o_rx_mac_inframe is set to 1. When the packet ends, o_rx_mac_eop_empty is set to the number of unused bytes in o_rx_mac_data. The o_rx_mac_eop_empty transition from 1→0 (between two consecutive segments) indicates the end of packet (EOP); the EOP ends in the segment where o_rx_mac_inframe is set to 0. RX MAC Segmented Client Interface

So for 400G: scan o_rx_mac_inframe[15:0] bit by bit. A 0→1 transition at bit i means segment i is the first segment of a new frame. A 1→0 transition at bit i means segment i-1 was the last segment of the previous frame, and o_rx_mac_eop_empty[(i*3)-1 : (i-1)*3] tells you how many bytes in that last segment are unused. The minimum number of bytes on the last cycle is 1. RX MAC Segmented Client Interface

Also note: the interface does not take direct backpressure. RX MAC Segmented Client Interface Your logic must be ready to consume data every cycle.

4. Verilog frame extraction example

I can't share a file, but here is a conceptual Verilog snippet to get you started. This is general guidance, adapt it to your pipeline and timing requirements:

// 400GE: 16 segments, 64 bits each, 3 eop_empty bits per segment
// Inputs (registered from IP):
//   o_rx_mac_valid
//   o_rx_mac_data    [1023:0]
//   o_rx_mac_inframe [15:0]
//   o_rx_mac_eop_empty [47:0]  // 3 bits per segment
//   o_rx_mac_fcs_error [15:0]

// Detect SOP: bit i is 1 and previous bit (or previous cycle's bit 15) is 0
// Detect EOP: bit i is 0 and previous bit is 1

reg prev_inframe; // bit 15 of inframe from previous valid cycle

always @(posedge clk or posedge rst) begin
    if (rst) begin
        prev_inframe <= 1'b0;
    end else if (o_rx_mac_valid) begin
        prev_inframe <= o_rx_mac_inframe[15];
    end
end

integer seg;
always @(posedge clk) begin
    if (o_rx_mac_valid) begin
        for (seg = 0; seg < 16; seg = seg + 1) begin
            // Determine "previous" inframe bit
            // For seg==0, previous is prev_inframe (last bit of prior cycle)
            // For seg>0,  previous is o_rx_mac_inframe[seg-1]
            wire prev_bit = (seg == 0) ? prev_inframe
                                       : o_rx_mac_inframe[seg-1];

            // SOP: transition 0->1
            if (!prev_bit && o_rx_mac_inframe[seg]) begin
                // Segment 'seg' is the first segment of a new frame
                // Data bytes: o_rx_mac_data[seg*64 +: 64]
            end

            // EOP: transition 1->0
            if (prev_bit && !o_rx_mac_inframe[seg]) begin
                // Segment 'seg-1' was the last segment of a frame
                // (handle seg==0 case: EOP was in segment 15 of prev cycle)
                // Empty bytes in that last segment:
                //   o_rx_mac_eop_empty[(seg-1)*3 +: 3]  (for seg > 0)
                // FCS error:
                //   o_rx_mac_fcs_error[seg-1]           (for seg > 0)
            end

            // Mid-frame: inframe[seg]==1 and no transition
            // Data is valid payload bytes for the current frame
        end
    end
end

Key implementation notes:

You need to track prev_inframe (the inframe state at the end of the previous valid cycle) to correctly detect SOP/EOP at segment 0 of the current cycle.

Multiple SOP/EOP pairs can occur within the same 16-segment cycle — your loop must handle all of them, not just the first.

For each EOP, check o_rx_mac_fcs_error[seg] to know if the frame is good. The o_rx_mac_fcs_error signal is valid only on EOP segments; a high value indicates the frame had an FCS error, was malformed, was undersized, or was oversized and truncated because the MTU enforcement feature of the RX MAC was enabled. RX MAC Segmented Client Interface

The o_rx_mac_eop_empty[2:0] per segment tells you how many bytes at the MSB end of that 64-bit segment are unused (padding), so valid bytes = 8 − empty_count.

Since the interface gives no backpressure, you'll typically want a wide FIFO or buffer behind this logic to absorb bursts.

The 1518-byte MTU you mentioned means a maximum frame spans at most ⌈1518/8⌉ = 190 segments = ~12 cycles at 400G, so your frame reassembly buffer needs to handle that depth. Small frames (60 bytes = 8 segments) can easily pack 2 per cycle, confirming your intuition about multiple SOPs/EOPs.