DP83867CS: Handling of carrier-extend symbols by phy receive side.

Do you have expect to have the packets not byte aligned in your system ?

Regards,

Geet

I don't believe it is an alignment concern, but question to if the packet extend symbols blocked from the MAC layer as described here:

https://www.cse.wustl.edu/~jain/cis788-97/ftp/gigabit_ethernet/index.html#CAR

The MAC has issues if carrier extend symbols are received at the MAC interface.

More specifically, are those symbols ever passed after the end-of-frame symbol delimiters.

OK, we believe your question refers to this phrase from clause 36.2.4.15.1 "EPD rules":

If /R/ is transmitted in an even-numbered code-group position, the PCS appends a single

additional /R/ to the code-group stream to ensure that the subsequent /I/ is aligned on an even-

numbered code-group boundary and EPD transmission is complete;

The answer is that the MAC PCS supports receiving the /T/R/I/ (EPD2 - for even-aligned frames) and /T/R/R/I/ (EPD3 - for odd-aligned frames) code-groups.

So yes, a single carrier extend /R/ octet for alignment is ok (meaning the second /R/ in EPD3).

What the MAC PCS does not support is more /R/ octets than /T/R/R/I/, e.g. /T/R/R/R/.... So if the PHY uses /R/ for any other purposes (not specified by the spec) than to encode the termination of a frame, this is not disallowed by the Ethernet spec, but also not supported by the MAC PCS, which will mark those frames as errored.

Can you please clarify if this extra carrier-extend is a possibility for this PHY?

Thanks,

Dave