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

RE: Clause 49 /A/ /K/ /R/ on XGMII question




Steve,

The RS doesn't do anything with /E/s that occur during idle. Actually, the
RS doesn't have any error counting facility. Therefore, it doesn't matter
whether it treats an /A/ /K/ /R/ during idle as an /E/ or an /I/. 

Currently, a Start on lane 0 causes assertion of DATA_VALID regardless of
what proceeded it. Therefore, currently, it doesn't matter with regard to
start of packet whether the prior character was /A/ /K/ /R/ /I/ or /E/. I
think it would be better protection against a burst error occuring during a
packet to require that the 4 bytes before the Start character be idle.

During a frame, the RS treats any control character other than /T/ as an
error. This is the right thing and is consistant with what you want.

The rule for deassertion of DATA_VALID is worded a bit oddly in the current
draft. It does say that /E/ doesn't change the DATA_VALID_STATUS. I believe
it intended to say that any control character other than /E/ or /S/ results
in DATA_NOT_VALID.  Therefore, the one difference between receiving /A/ /K/
/R/ and receiving /E/ is that the former will deassert DATA_VALID while the
latter will leave it asserted. Both cases cause the RS to enforce an error
in the packet.

Therefore, with the possible exception of packet start (and the need for a
minor editorial tweak for packet end), RS is doing the right thing.

Pat

-----Original Message-----
From: Steve Haddock [mailto:shaddock@extremenetworks.com]
Sent: Wednesday, February 14, 2001 4:47 PM
To: 'Grow, Bob'; 'pat_thaler@agilent.com'; jgaither@rocketchips.com;
stds-802-3-hssg@ieee.org
Subject: RE: Clause 49 /A/ /K/ /R/ on XGMII question



I agree with Bob's philosophy when the control characters are received
within a data frame.  I strongly disagree when they are received during
idle.  It is important to have very strong validity checks for start and end
delimiters.  Beyond that there is no value to translating control characters
received during idle to error control characters, especially at the XGMII
since it will not affect have anything in the MAC.  If you are trying to
count coding violations, including sequence violations, the appropriate
place to do it is in the PCS.  Even there I would advocate counting all
coding violations, but check sequence violations only for assuring integrity
of data frames, and have the receiver be very permissive of control
characters received during idle.

Steve 

-----Original Message-----
From: Grow, Bob [mailto:bob.grow@intel.com]
Sent: Wednesday, February 14, 2001 4:18 PM
To: 'pat_thaler@agilent.com'; jgaither@rocketchips.com;
stds-802-3-hssg@ieee.org
Subject: RE: Clause 49 /A/ /K/ /R/ on XGMII question



I have some comments to submit on clause 46 to clarify the XGMII control
characters that should be treated in the same way as Error control
characters.  I plan to recommend that all received control characters except
Terminate (including the reserved control characters like unfiltered /A/,
/K/, /R/) in a frame be treated as Error control characters.  That
eliminates the need for a redundant filtering function in the PCS.  The
related part of the comments is to better define delimitation of a received
frame by improving the specification of DATA_VALID_STATUS being set to
DATA_NOT_VALID.  

All of this is consistent with what Pat says below.

--Bob Grow

-----Original Message-----
From: pat_thaler@agilent.com [mailto:pat_thaler@agilent.com]
Sent: Wednesday, February 14, 2001 2:52 PM
To: jgaither@rocketchips.com; stds-802-3-hssg@ieee.org
Subject: RE: Clause 49 /A/ /K/ /R/ on XGMII question



Justin,

The XGXS only converts /A/, /K/, and /R/ to /I/ when they occur in a whole
column: an ||A||, ||K||, or ||R|| ordered set. Therefore, one type of error
that would cause /A/, /K/, or /R/ on the XGMII output from an XGXS would be
a bit error that changed the value of one or more bytes in an ordered set.
If such an error happens, there is no particular reason for a 10GBASE-R PCS
to change the remaining /A/, /K/ and /R/ symbols to an /E/. We have code
table entries for them and replacing them with something else would
complicate implementation.

The primary purposes of sending an /E/ are: 
  to avoid changing an unencodeable input into something that might produce
an undetectable error. 
  to propogate special error detection that preserves delimiter Hamming
distance so that code dependent 0- to 3-bit errors don't produce
undetectable errors.

Neither of those purposes would be served by changing a spurious /A/, /K/ or
/R/ into an /E/. Furthermore, the RS has to handle receiving these /A/, /K/
and /R/ code groups because an XGXS might be directly connected to the RS.
If one believes that /A/, /K/ and /R/ should not be allowed to exist at the
XGMII interface, than it is the 10GBASE-X/XGXS coding rules that should be
changed and not 10GBASE-R.

Regards,
Pat 

-----Original Message-----
From: Justin Gaither [mailto:jgaither@rocketchips.com]
Sent: Wednesday, February 14, 2001 11:29 AM
To: 802.3ae
Subject: Clause 49 /A/ /K/ /R/ on XGMII question


Hello,
	Page 345 line 30-31 says "The codes for /A/ /K/ and /R/ are used on
the
XAUI interface to signal idle.  They are not present on the XGMII when
no errorrs have occurred, but certain bit errors cause the XGXS to send
them on the XGMII."

What types of errors would this be? and why would we want allow them to
continue through the 10GBase-R, into the optional WIS and onto the link?

Should these be replaced by /E/?


-- 
Justin Gaither                       Phone: 512-306-7292  x529
RocketChips a Division of Xilinx     Fax:   512-306-7293
500 N. Capital of TX Hwy.
Bldg 3                         email: jgaither@rocketchips.com
Austin, TX 78746               WWW:   www.rocketchips.com