If using the v3.0 or earlier 10-Gigabit Ethernet PCS/PMA core, under certain conditions it is possible to underflow the RX elastic buffer. Some repetitive patterns of jumbo frames with small InterFrame gaps can cause an underflow in the Elastic Buffer, resulting in a corrupted frame. The likelihood is largely dependent on the PPM difference in the clocks, and the size of the jumbo frames. The buffer inserted idles between 1/4 full and empty, and this sometimes resulted in not enough margin to allow cross clock domain signaling to insert idles and avoid underflow.
At 200ppm, with the Xilinx device as the faster-clocked receiver, if one or more Ethernet frames total more than around 20KBytes of data with only minimum IFGs in between (12 or 16 bytes), there is a chance that the Elastic Buffer will not be able to insert IDLEs and may run empty, causing an /E/ block followed by Local Fault, corrupting the current frame. The chance is greatly reduced with wider and/or more numerous InterFrame gaps.
In v4.0 (available in Vivado Design Suite 2013.3) and v2.6Rev. 3 (available in ISE Design Suite 14.7), the buffer has been updated to insert idles when the buffer is less than 1/2 full to allow more margin in the buffer.
This update also increases the nominal latency in the core. In v4.0 of the core, a typical latency with the buffer half full has been measured to be approximately 1831 bit times (1831/66 = 27.75 words). Before buffer overflow, the maximum latency was measured at 2723 bit times. The maximum latency is being measured on the RX path as the latency just before the buffer overflows. Under normal operation the buffer will be able to do clock correction during the IFGs and will not overflow.