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