RE: From serial PMD call 5 June
Tom,
You have asked a great question here. Of course, the question I read might
be different than the one you asked :-).
I see this is a derivative question to the one Piers asked (and has been
asking for a while) at the last meeting: are we writing a component or a
system level specification. From the perspective of the standard, we are
writing a system level specification. This leaves unresolved how the
component manufacturers and the system integrators are to negotiate the
margin needed for a successful implementation. I have more than sufficient
lab results to prove that FC and GbE did not resolve this issue.
From the perspective of the system integrator, using the new test methods
with the virtual embedded BERT (VEB?), there is no need to represent "other"
jitter that would be inherent in a system since the "other" jitter is
already in the system. I would propose that the only reason to add margin
would be to compensate for systematic measurement error (potentially due to
effects that are a result of the simplifying assumptions of our models, for
example) or to compensate for variations in temperature and other
uncontrolled "environmental" factors (power and ground noise; EMI from
adjacent equipment, etc).
The system company and system company's customer would probably be more
interested in seeing extra system-level margin represented as margin in the
BER curves.
There remain four corners to the question: [System specification/test,
Component specification/test] X [Tx, Rx]
To add to Anthony's comments, we seem to have (at least) two places where we
are adding margin:
1. Intentional addition of the SJ.
2. Measurement error.
The problem with the measurement error is that these will vary. If the
errors were constant (consistent), these would add margin. If not
consistent, these could subtract margin. Unfortunately, I don't know if our
test specification bounds this problem or not.
We, therefore, have several reasons why margin is a good idea. But, we also
have several ways to add or to display the margin.
So, can we reduce all of this to a method that supports both the standard,
the system developers, and the component manufacturers?
jonathan
> -----Original Message-----
> From: Lindsay, Tom [mailto:tlindsay@xxxxxxxxxxxxxxxxxxxx]
> Sent: Friday, June 08, 2001 8:17 AM
> To: DAWE,PIERS (A-England,ex1); 802.3ae Serial
> Subject: RE: From serial PMD call 5 June
>
>
>
> The minutes below represent the ideas very clearly, and I
> agree with the
> differences in probability distribution. For DDJ, this is especially
> true for the randomized data that results from scrambling. So, I agree
> that testing with SJ will enforce some margin.
>
> In FC, SJ above the corner frequency was intended to represent "other"
> jitter that may occur in a real system that would not be seen in a
> compliance test. So, what quantity of other jitter we expect to occur?
> I'm not quite ready to think this is 0.
>
> These 2 points tend to contradict. Do they perfectly offset (per
> Anthony's proposal)? Obviously a supplier would rather not
> have to test
> with "other" jitter, but a system customer may be glad to
> have it there.
>
> Tom
>
> -----Original Message-----
> From: DAWE,PIERS (A-England,ex1) [mailto:piers_dawe@xxxxxxxxxxx]
> Sent: Friday, June 08, 2001 6:02 AM
> To: '802.3ae Serial'
> Subject: From serial PMD call 5 June
>
>
>
> Jitter spec numbers
> -------------------
> Opinion on the call was that:
>
> 0.35 UI of DJ was too much; nearer 0.3 UI would be fairer
> 0.015 UI of sigma_RJ was too little; 0.016 suggested
> The extra 0.05 UI of sinusoidal jitter in the stressed
> sensitivity test
> was
> a significant burden.
> Some believed that our draft jitter requirements are more
> demanding than
> SONET.
>
> Anthony Sanders suggested that the stressed eye should contain the
> sinusoidal jitter as a component of the deterministic jitter, rather
> than in
> addition to it. SJ is more stressful than "regular" DJ as its
> probability
> distribution is concentrated towards the extremes. As these
> minutes may
> not
> represent the ideas correctly, Anthony would put some slides on the
> reflector for discussion. Also Ali Ghiasi may be able to offer some
> information on CDR requirements (how many UI of eye opening needed).
>
> Next Draft
> ----------
> Is expected 11 June.
>
> Piers
>