RE: Clause 49 /A/ /K/ /R/ on XGMII question
Bob,
Thanks for the response. I realize upon reading my own email more
carefully that I was mistaken in my wording; I intended to write
"control characters other than /T/ and /E/ are treated like a /T/".
However, my main point was that the clause is not internally consistent with
regard to its description of how to handle control characters within a frame other
than /T/ or /E/. On this point, we agree. Since you will submit a comment on
this, I will take no further action other than to participate in the discussions
on this in the March meeting.
Regards
Andrew Brierley-Green
Philips Semiconductors
bob.grow@xxxxxxxxx on 02/15/2001 03:17:34 PM
To: bob.grow@xxxxxxxxx@SMTP
David Brierley-Green/SVL/SC/PHILIPS@AMEC
cc: stds-802-3-hssg@xxxxxxxx@SMTP
Subject: RE: Clause 49 /A/ /K/ /R/ on XGMII question
Classification:
Andrew:
There are two RS functions in this area, and they are not identical based on
the current positions of the committee. Though the delimitation of frames
is closely related to the reception of invalid control characters, a
received control character may be treated like an Error character, or like
both an Error and Terminate control character. Your careful reading of the
clause points out the need to fix some minor inconsistencies, because your
conclusions aren't the same as my understanding of the position of the
committee.
The RS has to delimit frames. The delimitation of received frames to MAC is
through the setting of DATA_VALID_STATUS. The start of frame is consistent
and generally agreed to. The definition of the end delimiter is not clear
and consistent plus there is some disagreement within the group. Draft 1.0
ended the frame on any control but Terminate (as you describe below), but
that was changed so that Error would not end the frame, thus allowing
certain MIB counters to continue to count the bytes in the bad frame). The
involved sections of 46.1.6.5.3, 46.2.5 and 46.3.3 must all agree. I would
recommend that the relevant parts of 46.3.3 be written more like 46.2.5
referencing DATA_VALID_STATUS so that 46.1.6.5.3 is the only thing defining
a frame. I don't believe I had any D2.0 comments that allowed me to fix
this, and would have been overstepping my authority as editor had I just
made the above changes in D2.1 (consequently, I will make comments on D2.1).
Delimiter robustness was discussed on D1.0, but the subtask force meeting
decided not to enhance the robustness of either Start or Terminate
delimiters by requiring adjacent Idle characters. The were no D2.0 comments
suggesting Idle before Start or Idle after Terminate. Because of the
previous position of the subtask force, I would recommend anyone that
recommends enhancing delimiters have some numbers to justify the change.
The forcing of a CRC error is a related but separate function. I believe an
aligned Start control character or Error control character received when
DATA_VALID_STATUS = DATA_VALID should cause a CRC error but no change in
DATA_VALID_STATUS. A Reserved, Sequence, Idle or unaligned Start control
character would require the RS to assure a CRC error as well as setting
DATA_VALID_STATUS = DATA_NOT_VALID. This allows counters on bad frames to
behave in a manner similar to previous generations of Ethernet.
As Pat previously pointed out, the RS has no error counters, so when
DATA_VALID_STATUS = DATA_NOT_VALID, nothing is passed to the MAC.
Therefore, no errors in Idle are counted at the RS or above.
--Bob Grow
-----Original Message-----
From: david.brierley-green@xxxxxxxxxxx
[mailto:david.brierley-green@xxxxxxxxxxx]
Sent: Thursday, February 15, 2001 11:20 AM
To: bob.grow@xxxxxxxxx
Cc: stds-802-3-hssg@xxxxxxxx
Subject: 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