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

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. quoted by Doug below doesn't agree
with the informative description of the ||T|| ordered set on p311 of
D4.0 in, to wit:

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.

(My capitals).

Which in combination with Doug's observation, has left me more confused
than ever.

Perhaps another recirculation comment is required?


/ /\/\ 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. 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:                  (|)