RE: Clause 48: Errors after T.
Jonathan,
If you look at the way the decoder is specified in Clause 36, at any time it
only looks at the half of the table for the current disparity. Therefore, if
it sees an /A/ or /K/ character (or any other character) which is incorrect
for the current running disparity, it decodes that as an /E/. If a character
doesn't follow the rules, it is an error. The decoder has no way of
determining whether that character was errored or if an earlier error caused
the character to have a disparity error. We don't try to interpret errors.
By the way, the notation ||x|| represents an ordered set. The notation for a
character is /x/.
Regards,
Pat
-----Original Message-----
From: Jonathan Thatcher [mailto:Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx]
Sent: Tuesday, March 27, 2001 3:42 PM
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