| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Rich,
There isnt a codeword defined for /SEEE/EEEE/ - the only allowable /S/
is with ZZZZ/SDDD or SDDD/DDDD. ZZZZ/SEEE is also not supported.
In my EOP case, I made a mistake. I meant to insert a correct /T/.
So the EOP example should have been XAUI in -> /EDTR/KKKK/. Again, this
cannot be directly mapped, because the 66b EOP codeword does not support
Z control bytes before the /T/ mapping. The only options are
TZZZ/ZZZZ, DTZZ/ZZZZ, DDTZ/ZZZZ, DDDT/ZZZZ (+ the other 4 options).
Frame SOP and EOP are dealt with in a special way by looking at the first
embedded 8-bit type byte only. And this does not support /E/ after /S/
or /E/ before /T/. (Sorry I am mixing my notations here, but I'm sure
you follow what I am saying).
Regards,
Una
-----Original Message-----
From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
Sent: 11 April 2000 08:40
To: HSSG
Subject: Re: XGMII a/k/r and XGXS - PCS Interface
Una,
I agree with Rick that the safest and simplest approach is to generate an error
frame whenever an error is detected in the received signal or needs to be forced
into the transmitted frame. This includes all boundary conditions as follows:
a) SOP Case:
1) XAUI in -> /SDED/DDDD/; 66B out -> /SEEE/EEEE/
2) XAUI in -> /KKEK/SDED/; 66B out -> /KKEK/SEEE/ (pending resolution of
/A/K/R/ vs. /I/ issue)
Note that the /S/ is preserved and the "almost" Idle pattern in the first column
of (2) is a secondary indication of a packet boundary.
I don't like the idea of "carrying" over the error information to the next 66B
frame.
b) Mid Packet:
XAUI in -> /DDED/DDDD/; 66B out -> /EEEE/EEEE/
c) EOP Case (with 2 residual bytes):
1) XAUI in -> /EDKR/RRRR/; 66B out -> /EEKR/RRRR/
2) XAUI in -> /EDKK/AAAA/; 66B out -> /EEKK/AAAA/
The EOP is lost anyway and the /K/R/ in lanes 2 and 3 are additional errors and
no help. The /RRRR/ in the second column of (1) serves as an indication that the
EOP has been lost.
(2) indicates a more likely error scenario with proper XAUI Idle encoding.
Best Regards,
Rich
--
> Una Quinlan wrote:
>
> 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
-------------------------------------------------------
Richard Taborek Sr. Phone: 408-845-6102
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Fax: 408-845-6114
2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com