RE: Clause 48: Errors after T.
Boaz,
As Pat mentioned, this was discussed in the last meeting, and the RS/XGMII
group voted almost unanimously (10-1 or 9-1) to put this checking in the
PCS. There were comments submitted against Clause 46 and Clause 48 by Pat
Thaler, and we implemented the one in Clause 48 with changing the check_end
function. I've got a feeling that this is the way it is going to stay,
since there was very little opposition to how we ended up implementing it in
Clause 48 during the last meeting. Changing it would mean changing Clause
46 and Clause 48. As it stands now, I don't believe that anything is
broken, and therefore doesn't need to be fixed.
Eric
UNH InterOperability Lab
-----Original Message-----
From: owner-stds-802-3-hssg@xxxxxxxx
[mailto:owner-stds-802-3-hssg@xxxxxxxx]On Behalf Of Boaz Shahar
Sent: Thursday, March 29, 2001 4:59 AM
To: 'pat_thaler@xxxxxxxxxxx'; Boaz Shahar;
Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx; jgaither@xxxxxxxxxxxxxxx
Cc: stds-802-3-hssg@xxxxxxxx
Subject: RE: Clause 48: Errors after T.
Pat,
Thank you for the clarifications regarding task partitioning between the RS
and the MAC. In view of this, I think the proposal may be modified to be:
"Instead of doing the "Copy Back" / "Push Back" operation in the PCS, the
RS/MAC will be looking at the column following the ||T||, and will declare
the packet as erroneous one upon detection of one or more /E/ characters in
this column. The PCS does not refer the last column in a different way than
any other column, and always maps Code Group Bad to /E/"
Now, you're saying you discussed it in the last meeting and decided not to
do it? And if so: Does the justification for rejecting it is that: "
">It is the responsibility of the PCS to
> perform its code
> dependent checks and ensure that any error sent to the RS/MAC
> falls within
> the frame."
?
Thx.,
Boaz
> -----Original Message-----
> From: pat_thaler@xxxxxxxxxxx [mailto:pat_thaler@xxxxxxxxxxx]
> Sent: Thursday, March 29, 2001 4:52 AM
> To: boazs@xxxxxxxxxxxx;
> Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx;
> pat_thaler@xxxxxxxxxxx; jgaither@xxxxxxxxxxxxxxx
> Cc: stds-802-3-hssg@xxxxxxxx
> Subject: RE: Clause 48: Errors after T.
>
>
> Boaz,
>
> The MAC does not check for /E/ codes. It only checks CRC. The
> RS ensures
> that an /E/ in the packet produces a CRC error. Of course,
> since the RS and
> MAC are usually in the same device, the implementation can
> short cut this by
> making sure it reports a CRC error whenever it detects an /E/ but I am
> talking here about the structure of the standard by which we
> are bound.
>
> Different codes have different techniques necessary to
> preserve the Hamming
> distance of the code and protect its delimiters. For
> instance, the checking
> for the 64B/66B code requires checking that the frame
> following a T frame is
> an appropriate type. It is the responsibility of the PCS to
> perform its code
> dependent checks and ensure that any error sent to the RS/MAC
> falls within
> the frame.
>
> This is a conscious decision that we made. The Clause 47 and
> 48 subtask
> forces considered it again at the last plenary to make the decision of
> whether the RS should check for an /E/ following the /T/ in
> the |T| column
> or whether the PCS should ensure that an /E/ appeared in the frame. We
> decided to maintain our approach and leave the responsibilty
> for this code
> dependent check with the PCS.
>
> Pat
>
>
> -----Original Message-----
> From: Boaz Shahar [mailto:boazs@xxxxxxxxxxxx]
> Sent: Wednesday, March 28, 2001 12:34 AM
> To: 'Jonathan Thatcher'; 'pat_thaler@xxxxxxxxxxx';
> jgaither@xxxxxxxxxxxxxxx
> Cc: stds-802-3-hssg@xxxxxxxx
> Subject: RE: Clause 48: Errors after T.
>
>
> Jonathan,
> According to Pat comment, the E code on the XGMII occurs in
> both the /K/ (or
> /A/) column after the ||T|| and the associated lane data that
> is in the
> ||T|| column (Or the column before if the RD error is
> discovered in the
> ||T|| column). This is not necessary, because the MAC can
> mark the packet as
> erroneous according to the E code in the cycle after packet
> termination.
> Anyway, it has to calculate the FCS there, so it is just
> another source of
> error. It simpler there, because you don't have to "copy
> Back" or "push
> back" errors.
>
> Boaz
>
> > -----Original Message-----
> > From: Jonathan Thatcher
> > [mailto:Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx]
> > Sent: Wednesday, March 28, 2001 1:42 AM
> > To: 'pat_thaler@xxxxxxxxxxx'; jgaither@xxxxxxxxxxxxxxx
> > Cc: stds-802-3-hssg@xxxxxxxx
> > Subject: RE: Clause 48: Errors after T.
> >
> >
> >
> > In case there is any confusion here about what the rationale
> > is for this
> > push back:
> >
> > The 8B/10B code is not guaranteed to detect disparity errors
> > until the time
> > that a disparity biased code is shipped. To assure that a
> > disparity error
> > can not cross packet boundaries, we have chosen ||K|| and
> > ||A|| characters
> > to follow immediately after the ||T||. These characters are
> > disparity biased
> > (have unequal number of 1's and 0's) and will force any
> > latent disparity
> > error to be detected on the column immediately following the
> > ||T||. But,
> > since the ||K|| or ||A|| is not in error, the error must have
> > been in the
> > packet that precedes it. It is therefore necessary to have the error
> > backward propagated into the previous column.
> >
> > I recognize that this is in slight conflict with Pat's
> > statement below (at
> > least in some combinations of errors). By having both the
> > ||K|| or ||A|| and
> > the character preceding it in the same row within the ||T||
> > column turned
> > into an ||E||, there is an extremely low probability of the
> > error not being
> > detected by the higher layers.
> >
> > Perhaps, we should change the ||T|| definition to indicate not just
> > disparity errors via push back but also ||E||'s in the column
> > following the
> > ||T|| for extra resiliency. :-)
> >
> > jonathan
> >
> > -----Original Message-----
> > From: pat_thaler@xxxxxxxxxxx [mailto:pat_thaler@xxxxxxxxxxx]
> > Sent: Tuesday, March 27, 2001 12:29 PM
> > To: jgaither@xxxxxxxxxxxxxxx
> > Cc: stds-802-3-hssg@xxxxxxxx
> > Subject: RE: Clause 48: Errors after T.
> >
> >
> >
> > Justin and Howard,
> >
> > I think there is a misunderstanding here of what happens when
> > an error is
> > "pushed back". The character were the error was detected is
> > still sent as an
> > /E/. Since it didn't obey the coding rules, the decoder
> > doesn't know what
> > its "real" values was suppose to be. Therefore, the only
> > thing the decoder
> > can send in the character's place is an /E/. When we push an
> > error back, we
> > send an _additional_ /E/ in place of the character before the
> > one where the
> > error was detected.
> >
> > Justin also asked where the checking was put. The change was
> > executed by
> > adding check_end to the DATA_MODE_START state and modifying
> > the check_end
> > function to cover operation in that state.
> >
> > The only reason I can see to not push all errors back is that
> > it multiplies
> > the apparent errors. When it is only done on errors at the
> > end of a packet,
> > the effect on anything collecting error statistics is
> minimal. As the
> > current check_end function is written, an error is at most
> > doubled when it
> > occurs at the end of a packet. If we move all errors back,
> > then all errors
> > can be doubled, tripled, or quadrupled (because a packet may
> > go through 3
> > receive state machines on its path). This is a relatively
> > minor failing, but
> > I can't think of any particular advantage to pushing all
> errors back.
> >
> > Regards,
> > Pat
> >
> > -----Original Message-----
> > From: Justin Gaither [mailto:jgaither@xxxxxxxxxxxxxxx]
> > Sent: Tuesday, March 27, 2001 8:46 AM
> > Cc: 802.3ae
> > Subject: Re: Clause 48: Errors after T.
> >
> >
> > Thanks Rich, Bob, and Howard.
> >
> > This is the most compelling reason to NOT to push all errors back.
> > However, if a running disparity error occured in the ||S||
> > column, would
> > it not persist for quite a while until it encounterd a RD error
> > correcting code? Keeping the packet bad. However the check_end
> > function also looks for proper ||A|| and ||K|| placement after the
> > ||T||. If we have todo this, we might as well limit the
> > pushback during
> > this time as well.
> >
> > Thanks
> >
> > justin
> >
> > "Howard A. Baumer" wrote:
> > >
> > > Justin,
> > > If we push all errors back one column then the
> > error that was in
> > the
> > > ||S|| column could potentially get pushed out of the packet
> > and a good
> > > packet that should be indicated as bad would be produced.
> This is a
> > > very low probability but, none the less, we should error on
> > the side of
> > > caution.
> > >
> > > Howard
> > >
> > > Justin Gaither wrote:
> > > >
> > > > Everyone,
> > > > During the Plenary, it was determined that we need to
> > push an error that
> > > > occurs after the /T/ back 1 column so that it is included
> > inside the /S/
> > > > and /T/ delimeters. My question is, can we just push all
> > errors back on
> > > > column, or must we determine if it is in the column
> > following a //T//?
> > > >
> > > > I could not find this in D2.3, where did it get put?
> > > >
> > > > Thanks
> > > >
> > > > --
> > > > 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
> > > >
> > > >
> > --------------------------------------------------------------
> > ----------
> > > > Name: jgaither.vcf
> > > > jgaither.vcf Type: VCard (text/x-vcard)
> > > > Encoding: 7bit
> > > > Description: Card for Justin Gaither
> >
> > --
> > 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
> >
>