Re: Clause 48: Errors after T.
I agree it isnt broken. It should be left alone.
justin
Eric Lynskey wrote:
>
> 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
> > >
> >
--
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
begin:vcard
n:Gaither;Justin
tel;fax:512-306-7293
tel;work:512-306-7292 x529
x-mozilla-html:TRUE
org:Rocketchips, Inc.
version:2.1
email;internet:jgaither@xxxxxxxxxxxxxxx
title:Project Engineer
adr;quoted-printable:;;500 N. Capital of TX Hwy=0D=0ABldg 3;Austin;TX;78746;
x-mozilla-cpt:;20160
fn:Justin Gaither
end:vcard