RE: [802.3ae] Clause 48: Check_end Question
Dave,
I agree with Rich. We have check_end because a single bit error followed by
a string of neutral disparity characters in some cases will not be detected
until the next disparity detecting character. (To define my terms: neutral
disparity characters have the same encoding regardless of disparity,
disparity detecting
characters have different encodings for the two disparities. Disparity
flipping characters are disparity detecting characters that change the
running disparity.)
Data characters can be neutral disparity but all the K characters (the
special code-groups) are disparity detecting. We need to make sure that an
error detected at the K character after last data character in each lane
produces an error within the packet because that disparity error may have
been caused by a bit error earlier in that lane. For the lane with the /T/,
the /T/ does that and an error in the /T/ is a packet that ends without an
end delimiter - an error that the RS handles. That is why check_end doesn't
need to do anything for that column.
Pat
-----Original Message-----
From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
Sent: Thursday, January 24, 2002 7:55 PM
To: stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
Subject: Re: [802.3ae] Clause 48: Check_end Question
Dave,
All 8B/10B special code-groups terminate (detect) all running disparity
errors. /T/ is an 8B/10B special code-group.
Best Regards,
Rich
--
Dave Laske wrote:
>
> All,
> I'll add one more twist to the mix. Unless I understand disparity
> errors less than I think, I've never seen anyone comment about the case
> where a disparity error occurs in the same lane as the /T/ character,
> but isn't detected until the following column. For example (where X is
> a disparity error, + indicates positive character disparity, - indicates
> negative character disparity and 0 indicates neutral character
> disparity; "Xmit disparity" is correct/expected, "Rcvd disparity" is as
> received/incorrect):
>
> Lane n: D X T A
> Xmit Disparity: + - 0 +
> Rcvd Disparity: + 0 0 +
> ^- Disparity error not recognized until this point
>
> I claim that if we follow the intent of pushing back the disparity
> error to occur within the packet (i.e. prior to the /T/ character) we
> would want to respond thus:
>
> Lane n: D E T E
>
> We can't push the error back to the /T/ or we wouldn't recognize
> packet termination, right?. It would have to actually be pushed back
> two columns. Does this seem reasonable?
>
> Dave
>
> Gareth Edwards wrote:
> >
> > I guess it's also worth pointing out that the normative description of
> > the check_end function C48.2.5.1.4 quoted by Doug below doesn't agree
> > with the informative description of the ||T|| ordered set on p311 of
> > D4.0 in 48.2.4.3, to wit:
> >
> > \begin{quote}
> > Unrecognized running disparity errors which propagate to any Idle
> > code-groups in ||T|| or to the column following ||T|| are indicated as
> > /E/ in the preceding column IN THE SAME LANE in which the errors were
> > recognized. All ||I|| ordered_sets are selected to ensure that
> > propagated code violations are recognized and not propagated further.
> > \end{quote}
> >
> > (My capitals).
> >
> > Which in combination with Doug's observation, has left me more confused
> > than ever.
> >
> > Perhaps another recirculation comment is required?
> >
> > Gareth
> >
> > --
> > / /\/\ Gareth Edwards mailto:gareth.edwards@xxxxxxxxxx
> > \ \ / Design Engineer
> > / / \ System Logic & Networking Phone: +44 131 666 2600 x234
> > \_\/\/ Xilinx Scotland Fax: +44 131 666 0222
> >
> > "Douglas T. (Doug) Massey" wrote:
> > >
> > > Gentlemen,
> > >
> > > I've just joined the reflector after an extensive search of your
archives
> > > in an effort to answer my question. The last discussion of the
check_end
> > > function was back in May 2001, so hopefully things have settled down
> > > enough so that there's a concrete answer. I realize it's poor
netiquette
> > > for a newbie to just start firing off questions, but *really*, I spent
> > > the whole weekend searching the archive. While watching football.
:-)
> > >
> > > My question:
> > >
> > > The check_end defintion in C48.2.5.1.4 says that an /E/ is returned
> > > in all lanes less than n in ||T|| (where n is the lane number of the
/T/
> > > in ||T||) for which an RD error or any code-group other than /A/ or
/K/
> > > is recognized in the column after ||T||. Did this really mean to
apply
> > > to the *entire* column following ||T||, or just the corresponding lane
in
> > > the column following ||T||, for each lane less than n?
> > >
> > > If the receiver sees this input:
> > >
> > > ... D D A R ...
> > > ... D D A R ...
> > > ... D T A R ...
> > > ... D K A* R ...
> > >
> > > where "A*" is an A with a disparity error, should the receiver return
> > > this as a response:
> > >
> > > ... D E I I ...
> > > ... D E I I ...
> > > ... D T I I ...
> > > ... D I E I ...
> > >
> > > It seems the A* disparity error is clearly *not* part of the preceding
> > > data packet, or the error would have been caught by the
disparity-biased
> > > /K/ that preceded it. Not only is the single error reported twice (as
> > > /E/ is replacing the two data code-groups in lanes 0 and 1 of ||T||),
> > > but it's reporting an error that occurred *after* the data packet.
:-\
> > >
> > > The check_end definition goes on to say that /E/ is returned for all
> > > lanes greater than n in the column preceding ||T||, for which an RD
error
> > > or a code-group other than /K/ is recognized in the corresponding lane
> > > of ||T||. The "corresponding lane" part here makes me wonder why that
> > > phrase wasn't used in the first half of the defintion. I presume it's
> > > used in the second half of the definition so that a single RD error in
> > > the in this example:
> > >
> > > ... D T A R ...
> > > ... D K A R ...
> > > ... D K A R ...
> > > ... D K* A R ...
> > >
> > > won't cause this kind of response:
> > >
> > > ... D T I I ...
> > > ... E I I I ...
> > > ... E I I I ...
> > > ... E E I I ...
> > >
> > > By adding "corresponding lane", only the lane 3 error is pushed-back
> > > inside the data packet and the data packet ends up with only one error
> > > (which is the right number, after all). This makes good sense -- why
> > > doesn't it apply to the first half of the check_end defintion?
> > >
> > > Any insights into this situation?
> > >
> > > Doug
> > > -- -------------------------------------------------------------------
> > > ___, Doug Massey, ASIC Digital Logic Designer
> > > \o IBM Microelectronics Division, Burlington, Vermont |>
> > > | Phone: (802)769-7095 t/l: 446-7095 fax: x6752 |
> > > / \ |
> > > . My homepage: http://doug.obscurestuff.com (|)
>
> --
> Dave Laske Motorola SPS
> Phone: (847) 413-2524 1501 Woodfield Rd., Suite 110E
> Fax: (847) 413-2596 Schaumburg, IL 60173
> e-mail: Dave.Laske@xxxxxxxxxxxx M/D: CHG LOC: IL03
---------------------------------------------------------
Richard Taborek Sr. Intel Corporation
XAUI Sherpa Intel Communications Group
3101 Jay Street, Suite 110 Optical Strategic Marketing
Santa Clara, CA 95054 Santa Clara Design Center
408-496-3423 JAY1-101
Cell: 408-832-3957 mailto:rich.taborek@xxxxxxxxx
Fax: 408-486-9783 http://www.intel.com