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