RE: XGMII a/k/r and XGXS - PCS Interface
I have not yet seen a response to the below message I sent last
Friday. My Email is flaky sometimes. Could you please re-send it.
At 01:18 PM 4/7/00, Una Quinlan wrote:
>Consider a case where 1 of the 4 HARI deserialisers in the PHY looses bit
>alignment (moves off by one bit). We now have a problem where the receive
>sync state machine on that lane will lose sync, and the decoded 10B stream
>will have errors. In 1000BASE X PCS Receive, we would have terminated the
>packet with error, and ignored 10B input until SYNC_ACQUIRED became true.
>In my proposed XGXS Receive statemachine, this could equate to terminating
>the packet with XGMII /e/ and /t/ flagging bad packet. Then the PCS transmit
>state machine would map this into a 66b codeword indicating packet errors
>If there is no state-machine, what will the PCS output? If XGXS continues
>to present illegal codes, we want to ensure the packet gets terminated
>correctly, but how is this achieved in a predictable fashion?
I have not seen your proposed XGXS Receive State Machine. Can you
send a description or diagram to the reflector? I would be interested
in seeing your thoughts on it. Is it much different from the diagrams
on pages 27 & 28 in Rich's XAUI/XGXS Albuquerque presentation? These
were modified from the 802.3z diagrams in clause 36 Figure 36-9 on page
954 of the 1998 (doorstop) Edition.
As I understand the XAUI/XGXS operation, in the case where the XGXS
receiver does not have SYNC_ACQUIRED on all four lanes (which is
prerequisite to SKEW_ACQUIRED,) the XGXS would not source invalid codes.
It would source either the (e), (E), /e/, or /E/ (which ever code is
appropriate for the attached interface) to signal an error.
I think we are all saying the same thing,
Don Alderrou mailto:dona@xxxxxxxxxxx
nSerial Corporation Tel: 408-845-6105
2500-5 Augustine Dr. Fax: 408-845-6114
Santa Clara, CA 95054 http://www.nserial.com/