Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [802.3ae] Clause 48: Check_end Question


Gareth

The normative text for check_end has the same meaning as the text you quote.
The relevant sentence from the check_end definition is:
The XGMII Error control character is returned
in all lanes less than n in ||T||, where n identifies the specific Terminate
ordered-set ||T n ||, for which
a running disparity error or any code-groups other than /A/ or /K/ are
recognized in the column
following ||T||.

Error is returned in lanes less than n in ||T|| for which an error is
recognized in the column following the ||T||.

Doug's interpretation of the sentence is not correct. It does not say that
an error is returned in lanes less than n when an error occurs in the column
after the ||T||. The subtle thing in the sentence is "lanes ... for which".
For Doug's example

> 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:
>
the result would not be:
> ... D E I  I ...
> ... D E I  I ...
> ... D T I  I ...
> ... D I E  I ...
>
It would be

... D D I I ...
... D D I I ...
... D T I I ...
... D I E I ...

because there was not an error in lane 0 or 1 of the column after the ||T||.

The sentence is perhaps a little hard to read and the next sentence (the one
about returning an error in the column before the T) is written a bit more
clearly. Adding "in the corresponding lane" would hammer the point home
better (especially since when the next sentence uses it the reader thinks
that this sentence not having it means something), but it shouldn't be
essential.

Pat

-----Original Message-----
From: Gareth Edwards [mailto:Gareth.Edwards@xxxxxxxxxx]
Sent: Thursday, January 24, 2002 7:08 AM
To: Douglas T. (Doug) Massey
Cc: stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
Subject: Re: [802.3ae] Clause 48: Check_end Question

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                  (|)