2245 - Lattice ECP3: Is it OK to loop XAUI data from the RX XGMII to TX XGMII if the IPG is always between 5 and 8 bytes long?

2245 - Lattice ECP3: Is it OK to loop XAUI data from the RX XGMII to TX XGMII if the IPG is always between 5 and 8 bytes long?

Description:The IEEE 802.3ae Specification explains that it is possible for a 12 bytes IPG (Inter Packet Gap) to shrink to 5 bytes by the time it reaches the RX XGMII interface. This is due to many factors, including clock rate compensation. Practically, the shrinking is  due to removal of  //R// columns  at the RX XAUI PCS layer during clock rate compensation. In reality, with XAUI compliant transceivers, a 12 bytes of IPG should never sharing down to 5 bytes unless you are dealing with super jumbo frames (in the tens of  thousands of bytes of data). If this were the case, then, looping the data with 5 bytes long IPG from the RX XGMII to the TX XGMII is NOT IEEE 802.3ae compliant. In fact, the specification also requires that  a XAUI compliant transmitter maintain a minimum IPG of 12-bytes on the TX XGMII interface. Note that looping back from RX XGMII to TX XGMII using Lattice Semiconductor XAUI PCS cores should functionally work even if the IPG falls below 12 bytes. However,  any IPG of less than 9 bytes in length causes a problem for the link partner XAUI receiver. This is because an IPG length of less than 9 bytes never contains an //R// column  as per the IEEE 802.3ae XGMII  to code-group conversion rules . As a result, the RX XAUI PCS CTC (Clock Tolerance Compensation) logic will be unable to remove any //R// columns during clock rate compensation. This potentially causes the receiving XAUI PCS CTC to overrun.