RE: Clause 48: Errors after T.
Steve,
Yes, there is an error in your thought process. You describe the receive
path as
PCS -> XAUI -> MAC
That isn't the path. When a XAUI is present, the path is:
PCS -> PHY XGXS -> XAUI -> DTE XGXS -> RS -> MAC
The receive state machines specified in Clause 48 are a required part DTE
XGXS. It has to acquire sync on the lanes, acquire lane alignment, decode
and check data using exactly the same rules as are specified for the
10GBASE-X PCS. The MAC and the RS know nothing about 8B/10B code. The PCS
and the XGXS decode it and handle all its error cases.
There is no error in the draft here.
Pat
-----Original Message-----
From: Stephen.Finch@xxxxxx [mailto:Stephen.Finch@xxxxxx]
I've been following this thread for awhile and I still don't get it.
I understand the "desire" to propogate a XAUI disparity error back into
the packet in those cases where the error was after the T but still
within "striking distance" of the data, i.e., within one XGMII transfer.
The method, as defined in the draft, will do this for 50% of the times
it occurs.
YES, ONLY 50 % OF THE TIME.
The XAUI devices are between the MAC and the PCS. All of the work we
are doing fixes only those errors in the path from MAC -> XAUI -> PCS,
but in the path PCS -> XAUI -> MAC, the same, exact, identical sequence
of events that are detected and handled by the PCS will not be detected
UNLESS THE MAC DETECTS IT.
Now, if the MAC must detect it for the second case, why not let it
detect it for the first case as well, and remove the REDUNDANT LOGIC
from the PCS?
Is there an error in my thought process?
I've been (quietly) against the inclusion of this since I joined
802.3ae, but being a new comer I assumed I was missing something.
Regards,
Stephen Finch