2
\$\begingroup\$

I have a question seeking to clarify EXACTLY what happens during a GMII exchange between MAC and PHY. Specifically, regarding the TX_ER signal.

IEEE 802.3 Section 3:

TX_ER is driven by the Reconciliation Sublayer and shall transition synchronously with respect to the GTX_CLK. When TX_ER is asserted for one or more TX_CLK periods while TX_EN is also asserted, the PHY shall emit one or more code-groups that are not part of the valid data or delimiter set somewhere in the frame being transmitted. The relative position of the error within the frame need not be preserved. Figure 35–4 shows the behavior of TX_ER during the transmission of a frame propagating an error.

enter image description here

My Question: When TX_ER is asserted by the MAC (while TX_EN remains high), does the frame still leave the PHY with all other frame bytes still intact, and ONLY the bytes transmitted while TX_ER is high get jumbled? Or does the PHY completely stop transmitting the frame once an error signal is detected?

I am working on an FPGA design that should be able to drop or pass a frame based on its contents, and I am wondering if assertion of the GMII TX_ER signal to the PHY would be considered "dropping the frame" or not.

In the case of the bytes still leaving the PHY, it would seem that the packet would only be "dropped" because the Ethernet FCS would not match the contents of the packet. But the frame contents would still be received by the PHY on the other end, and so if the receiver side had access to the physical layer, the data could be potentially recovered (which is not acceptable in my case).

I have tested this using the network utility iperf, and it appears that the application data does not go through if TX_ER is asserted. However wireshark seems to tell me that there are still valid TCP packets being received, and I don't understand how that is possible if the physical layer CRC doesn't match the frame contents.

Any insight much appreciated.

Thanks!

\$\endgroup\$
1
\$\begingroup\$

From the excerpt of IEEE 802.3 that you posted:

When TX_ER is asserted for one or more TX_CLK periods while TX_EN is also asserted, the PHY shall emit one or more code-groups that are not part of the valid data or delimiter set somewhere in the frame being transmitted.

The packet still gets sent on the wire by the PHY. The PHY does not include a FIFO large enough for a whole packet, so there is no way for the PHY to drop the frame on an assert of TX_ER. What the PHY does do is insert an out of band error condition, usually in the form of invalid or error indication code words, that the PHY on the receive side will interpret and assert RX_ER. I believe only the data bytes that correspond to the error codewords will be changed, everything else will be received correctly. It doesn't seem like the PHY is required to error the exact bytes that correspond to the TX_ER assert so long as an error is inserted somewhere in the frame. The receive MAC should throw out the frame if RX_ER is asserted during reception (same as if the FCS is bad), but it could well be possible to recover some portion of the frame.

If you really want to make sure the packet never gets sent, what I would recommend is storing the packet in a FIFO and only releasing it from the FIFO once you've checked the frame and determined that you actually want to send it. However, this will add a packet length dependent latency, which may or may not be acceptable.

Here is an implementation of a FIFO that does exactly that; dropping frames that are marked as invalid with an asserted tuser signal: https://github.com/alexforencich/verilog-ethernet/blob/master/lib/axis/rtl/axis_frame_fifo.v .

\$\endgroup\$
  • \$\begingroup\$ Thanks much, that was my suspicion. I might end up holding the error signal high for the duration of the frame, since there are already enough FIFOs in my design (for other purposes) to allow the entire Russian army to properly cross clock domains. And +1 points for the code, coming in hot with an AXIS interface and everything! \$\endgroup\$ – Brett Oct 2 '16 at 22:33
  • \$\begingroup\$ Well, there is also an asynchronous version of the same FIFO module. As well as a stripped down MAC module. If you have the data in AXI format, why are you messing with it in GMII format? \$\endgroup\$ – alex.forencich Oct 2 '16 at 22:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.