RE: Clause 48: Errors after T.
Boaz,
Yes, that is the rationale for placing the requirement on the PCS rather
than the RS.
Pat
-----Original Message-----
From: Boaz Shahar [mailto:boazs@xxxxxxxxxxxx]
Sent: Thursday, March 29, 2001 1: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
> >
>