RE: Clause 48: Errors after T.
Jonathan,
The extension and the /T/ characters used in 1000BASE-X are disparity
detecting characters. All control characters are disparity detecting
characters. 1000BASE-X does have a requirement that errors in the extension
cause the frame to be discarded with a CRC error (see 35.2.1.5). This is not
necessary to catch errors that occurred within the packet and I can't recall
the rationale for it.
I would like to address your suggestion that an error after the ||T|| be
pushed back two columns. I believe this is unnecessary. Consider a packet
that ends:
lane 0 D D D A/K R
lane 1 D D T A/K R
lane 2 D D K A/K R
lane 3 D D K A/K R
(A/K means the character may be an /A/ or a /K/.)
What errors need to be propagated back into the frame to preserve the
Hamming distance provided by the running disparity checking? Only the first
disparity checking character after the data in each lane needs to be
propagated back. This is:
A/K in lane 0
T in lane 1
K in lane 2
K in lane 3.
Note that propagating each of these back one column moves them into the
frame. There is no need to propagate an error in the A/K of lanes 1 through
3 back two columns because such an error is not a left-over disparity error
from the frame. The T and the K's have already detected any disparity
problem that was create by an error in the frame.
One can try this for any other position of T and get the same result.
Regards,
Pat
-----Original Message-----
From: Jonathan Thatcher [mailto:Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx]
Sent: Wednesday, March 28, 2001 8:20 AM
To: 'Boaz Shahar'
Cc: stds-802-3-hssg@xxxxxxxx
Subject: RE: Clause 48: Errors after T.
Boaz,
First, let's jump to the bottom line. The real question here is where should
the "buffer" in the pipeline be designed, in the MAC or in the XGXS (I hope
that there is any question that it is needed, but read on). Or, should it be
in the required hardware or in the optional hardware. I vote for the
optional hardware.
Now, back to your comment.
Yours is a rationale point for the following reason: we have no similar
requirement in 1000BASE-X with regard to the /T/ and the /V/ (/E/). In fact,
a disparity error detected at he first idle following carrier extension
could be a fair "distance" from the /T/. I would be interested in knowing if
any implementations "back propagate" this error to the packet (frame).
Probability of an error of this kind existing and being undetected by the
CRC is much bigger than 1 part in 4 billion (though I don't have the time or
patience to figure out the exact number). Ideally, the latent disparity
error would have been detected during the /T/ (by having the /T/ be
disparity biased rather than disparity neutral) and indicated as an /V/ in
the "/T/" location. That would put the error indicator "inside the packet."
For XAUI, the error would be detected during the ||K|| or the ||A||. If
indicated in the ||K|| or ||A|| it would be "outside the packet." But,
indicating the error in the ||T|| might well indicate the error "outside the
packet" (e.g. an error in lane 3 where the /T/ is in lane 0 would indicate
/E/ after the /T/ when thought of as a serial flow). Since this already
violates the concept of indicating the error within the packet in which it
occurs, we could argue that violating it by one more column is of no
consequence.
But, it could equally be argued that this is a flaw and that the "push back"
should be two columns so that the error is always indicated within the
packet.
Hmmm.
Return to first paragraph...
jonathan
-----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
>