| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Brad,
I like this latest set of drawings. A notation for 66b codewords would
then allow us to represent the 64b/66b PCS output. Also, thanks to
other people for their responses, and pointers to presentations etc.
I have a few more questions on Error Encoding, for Rick.
I have referred to the Error codes case, and your response was that you
would transmit a ZZZZ/ZZZZ codeword with 8 'Error' types inserted. However,
there are some boundary cases in an Ethernet packet which this will not cover,
where an error byte must be inserted near the start or end of a frame:
(a) SOP Case:
Imagine XAUI presents a stream : /S/ /D/ /E/ /D/, /D/ /D/ /D/ /D/.
The PCS cannot replace this 64bit sequence with 8*error bytes because the
/S/ would be lost. When a similar condition occurred in the 1000BASE-X PCS,
we postponed the error flagging until the next suitable boundary:
For 64b/66b, this would mean transmitting the normal SOP, (SDDD/DDDD), and
then following it with /ZZZZ/ZZZZ/ (all errors).
(b) Mid Packet:
I this that it would be reasonable to replace any 8-byte data stream (with
at least one error byte) with ZZZZ/ZZZZ. (eg /D//D//E//D//D//D//D//D/).
The only requirement is that the PCS Receiver (at the other end of the fibre
link), does not terminate the packet in this case, but stay in the Packet
Data loop.
(c) EOP Case (with 2 residual bytes):
/E/ /D/ /T/ /K/ /R/ /R/ /R/ /R/. How could this be encoded? It may not be
possible to adopt an approach like the SOP case, where an Error codeword
is transmitted, and a delayed EOP indication follos. Because this would
eat into the IPG by up to 7 bytes.
Regards,
Una
-----Original Message-----
From: Booth, Bradley [mailto:bradley.booth@xxxxxxxxx]
Sent: 07 April 2000 17:56
To: HSSG
Subject: RE: XGMII a/k/r and XGXS - PCS Interface
Una,
Would the following representation be more to your liking? The first two
slides haven't changed much, but I added some new slides to define the MAC
to XGXS and the XGXS to PCS interfaces.
Cheers,
Brad