RE: Clause 48: Errors after T.
Given the fact that CRC gaurantees error check over 32 bit range, this is a
good
suggestion and I support it.
Regards,
Devendra Tripathi
VidyaWeb, Inc
90 Great Oaks Blvd #206
San Jose, Ca 95119
Tel: (408)226-6800,
Direct: (408)363-2375
Fax: (408)226-6862
> -----Original Message-----
> From: owner-stds-802-3-hssg@xxxxxxxx
> [mailto:owner-stds-802-3-hssg@xxxxxxxx]On Behalf Of Boaz Shahar
> 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
> >
>