# Re: [802.3ae] Clause 48: Check_end Question



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

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@xilinx.com
> \ \  / 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                  (|)

--