Re: [802.3ae] Clause 48: Check_end Question
Doug, Gareth,
10GBASE-X errors recognized by the PCS affect individual lanes. The
wording in the check_end function covers the case of multiple
independent errors. The check_end function insures that any one error in
the case of multiple errors (i.e. all lanes) will result is frame being
marked as containing an error.
Hope this helps.
Best Regards,
Rich
--
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 (|)
---------------------------------------------------------
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