Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: XGMII a/k/r and XGXS - PCS Interface

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