RE: Clause 49 /A/ /K/ /R/ on XGMII question
Bob,
I find the current wording in Clause 46 regarding treatment of control characters
within frames rather confusing. I want to check that my understanding of the
intent is correct. In 46.3.2.2, line 52, it is written "The RS shall treat any control
character received after a Start control character other than a Terminate
control character as an error, see 46.3.3.1." It is not clear to me what "treat as
an error" means but 46.3.3.1 explains how /E/ characters are to be handled by
forcing the MAC to detect an FCS error for this frame. This reference to 46.3.3.1
seems to imply that a control character after /S/, other than /T/ is to be treated
the same as if it was /E/. However, I believe that the intention was that any
control character following /S/ other than /T/ should actually be treated as
an end of packet delimiter and cause deassertion of DATA_VALID thereby
truncating the frame. In other words, one should treat any such control
character as a /T/ rather than an /E/. This view is supported by 46.2.5:
"the End of Packet delimiter is defined as the end of the last sequential data
octet preceding the Terminate control character, or other control character
causing a change from DATA_VALID to DATA_NOT_VALID." 46.1.6.5.3
states that DATA_VALID_STATUS will become DATA_NOT_VALID
for any control character in a frame other than a /S/ or an /E/. Based on
your email, I believe that the correct interpretation is that control characters
within a frame, other than /T/ are to be treated like a /T/, but you will
recommend that they be treated like an /E/ in the next draft. Could you please
confirm or correct my understanding.
Regards
Andrew Brierley-Green
Philips Semiconductors
pat_thaler@xxxxxxxxxxx@SMTP@xxxxxxxx on 02/15/2001 09:59:54 AM
Sent by: owner-stds-802-3-hssg@xxxxxxxx
To: stds-802-3-hssg@xxxxxxxx@SMTP
jgaither@xxxxxxxxxxxxxxx@SMTP
bob.grow@xxxxxxxxx@SMTP
shaddock@xxxxxxxxxxxxxxxxxxx@SMTP
cc:
Subject: RE: Clause 49 /A/ /K/ /R/ on XGMII question
Classification:
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@xxxxxxxxxxxxxxxxxxx]
Sent: Wednesday, February 14, 2001 4:47 PM
To: 'Grow, Bob'; 'pat_thaler@xxxxxxxxxxx'; jgaither@xxxxxxxxxxxxxxx;
stds-802-3-hssg@xxxxxxxx
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@xxxxxxxxx]
Sent: Wednesday, February 14, 2001 4:18 PM
To: 'pat_thaler@xxxxxxxxxxx'; jgaither@xxxxxxxxxxxxxxx;
stds-802-3-hssg@xxxxxxxx
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@xxxxxxxxxxx [mailto:pat_thaler@xxxxxxxxxxx]
Sent: Wednesday, February 14, 2001 2:52 PM
To: jgaither@xxxxxxxxxxxxxxx; stds-802-3-hssg@xxxxxxxx
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@xxxxxxxxxxxxxxx]
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@xxxxxxxxxxxxxxx
Austin, TX 78746 WWW: www.rocketchips.com