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

RE: [802.3ae] 64/66b Encoding phenomena




Justin,

The coding rules were set up to ensure a Hamming distance of 4. Part of that requirement is that no three bit error can cause a false start or end of frame. In order to acheive this, it is possible for an error in the block before a frame or the block following the frame to cause the frame to be dropped as if it had had an error. This is not a problem. We designed this for a low bit error rate link (less than 1 in 10^-12) so occurance of an error in the block before or after a frame should be low. Even if the error rate is not low, the number of bits in frames is much less than the number of bits in blocks immediately proceeding and following a frame. Therefore frames dropped due to errors that don't actually impact them should be a relatively small amount of lost frames (and if error rate is high, there is increased chance of errors within a frame that cause a false start or end so the care is definately needed.

An error that falls one to twelve symbols before an S or one to fifteen symbols after a T may cause a frame to be discarded depending on how the block boundary falls. This is not a problem.

Regards,
Pat


-----Original Message-----
From: Justin Gaither [mailto:Justin.Gaither@xilinx.com]
Sent: Friday, May 24, 2002 2:02 PM
To: 802.3ae
Subject: [802.3ae] 64/66b Encoding phenomena



Group,
	One of the Engineers here brought to my attention an interesting
problem with the 64/66b encoder.  The issue is that the data stream out
of the PCS could be very different depending upon where it is aligned
with respect to the 64 bit boundary.

Take this case:

Example stream:
DDDD DDDT IIIE EIII SDDD DDDD

Where :

S - Start

D - Data

T - Terminate

I - Idle

E - Error

This data stream can be interpreted two different ways depending on
where the 64 bit boundary falls.

1.  DDDD_DDDT, IIIE_EIII, SDDD_DDDD with block type fields of FF, 1E,
and 78 respectively. (T C S)

2.  DDDT IIIE, EIII SDDD corresponding to block type fields of B4 and 33
respectively, these are T_BLOCK_TYPES of T and S.



If you look on page 379 of the 10GBASE-R spec(D5.0) under T_BLOCK_TYPE
and Value C: pt a) it says a C vector is one with 8 valid control
characters other than /O/, /S/, /T/ and /E/.

The way I read this is that if you have 7 idles and 1 error come in
together in one 64 bit block, then the entire block is an E block.

Resulting in 1. becoming /T/ /E/ /S/
while 2. would remain  /S/ /T/

Additionally, if the entire block is /E/ then the /S/ that follows will
also be transformed into an /E/ as well according to the TX
statemachine, this seems rather unfair to corrupt the whole next packet
just be cause it did not fall on a certain boundary.

Please let me know what you think.

Justin





-- 
Justin Gaither                           Phone: 512-306-7292  x529
Xilinx, Communications Technology Div.   Fax:   512-306-7293
500 N. Capital of TX Hwy.
Bldg 3                         email: justin.gaither@xilinx.com
Austin, TX 78746               WWW:   www.rocketchips.com
                                      www.xilinx.com