Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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
> > 
>