ITU Jitter presentation
Hi all,
I just detected that the PDF writer has corrupted my presentation on ITU
jitter a bit. The description what the different colors meant was put to the
back of the drawing of slide 11 and made it invisible. So blue represents
fibre effect, yellow transmitter impairment, and red clock noise in that
drawing.
Regards Juergen
----------
Von: Rahn, Juergen (Juergen)
Gesendet: Freitag, 9. März 2001 15:55
An: Jonathan Thatcher; 'Tom Lindsay'
Cc: Serial PMD reflector (E-mail)
Betreff: AW: Jitter work for clause 52
Hi,
I would like to support the position that the standard should give
the
boundary to be tolerated while the implementor has to care for the
margins.
In general this means .
There will be a Curve , a filter slope and a constant section: The
jitter
generation has to be underneath this curve while the tolerance has
to be
above .
Regards Juergen
----------
Von: Tom Lindsay [SMTP:Tom.Lindsay@xxxxxxxxx]
Gesendet: Freitag, 9. März 2001 01:57
An: Jonathan Thatcher
Cc: Serial PMD reflector (E-mail)
Betreff: Re: Jitter work for clause 52
Jonathan -
FC set the golden PLL corner frequency (I prefer to think of
this as
the high-pass measurement corner frequency, since golden PLL implies
a test
method/equipment) and the Rx sine mask corner frequency to the same
value.
That value is baud/1667 (XAUI appears to be settling on the same
equation).
Clearly, having margin in products is desirable. How much
margin
must be built into the standard? The whole concept of the sinusoidal
sweep
for Rx tolerance already provides margin (recall that the sine
jitter is
added to the worst case jitter expected from the output of the cable
plant).
FC chose not to add more margin via the corner frequencies,
realizing that
anybody making a robust Rx would naturally move their corner up
anyway.
That is, the golden PLL should set the minimum requirements
for the
Rx, not a "well designed" Rx. Setting the 2 frequencies the same in
the
standard does not stop a supplier from doing better.
My recommendation is the same as Geoff's - make the corner
frequencies the same. Whether that is baud/1667, baud/2500, or
something
else is another topic.
Thanks, Tom Lindsay
Vixel
.
Jonathan Thatcher wrote:
Geoff,As you say, there is no change in this
document for
the Rx. We discussed this on the conference call. Sorry you weren't
available. I need to write it up for any discussion to make sense.We
are
planning to specify the Golden PLL, etc. But, not quite for the same
reasons
you list.Prior to getting this done, I would like to pursue a point
you make
below for general discussion. You mention that you think the Golden
PLL B/W
"should be equal to the breakpoint on the sinusoidal jitter
tolerance
mask..." and that "...this ensures compatibility of the transmitter
and
receiver."This is an interesting statement to me for a couple of
reasons:1.
I have been taught that for a system (link) to work well, the B/W of
the PLL
in the Tx and the PLL in the Rx must be different. The Rx must be
able to
follow variations caused by the Tx PLL. Given that this should be
true
across all chip and system conditions and variations, the delta
could be
significant. The result is that there is an inherent jitter caused
by the
difference in the breakpoints. To my knowledge, while this has been
discussed in a variety of forums in the past (e.g. the 10b chip
specification), I know of no case where this is documented or
specified.2.
The Golden PLL should be made to closely approximate the performance
of a
well designed Rx PLL and also provide a definitive standard for
measurement.
These two requirements conflict to some degree. Historically, we
have shown
preference to the later. Probably the worst mistake we could make
would be
to create a situation where the optimization of the Tx ends up in
conflict
with the optimization of the Rx design.3. I don't remember ever
seeing an
analysis aimed at defining the optimal specifications for the Golden
PLL wrt
other specifications. This, therefore, reduces to engineering
judgment.
Unfortunately, it is rare that we have any PLL designers amongst
attending
the PMD (optical) meetings.I assume that the SONET mask will be used
to test
the Rx. I would similarly assume that the Golden PLL will be used to
test
the Tx. If what I surmise above is correct, we would not want these
to have
the same break point (close perhaps, but not the same).Curiously, my
understanding is that most SONET PLLs are designed not against the
mask, but
against a corner frequency that has a certain probability of
occurrence
(maximum run length). Since this becomes a design trade-off
consideration,
not a standards requirement, we see a wide variety of specifications
for the
corner frequencies. If we design the specifications and conformance
testing
to continue to allow this kind of "personal initiative" and "market
differentiation" it has the potential to further complicate an
already
complicated scenario.jonathan-----Original Message-----
From: Geoffrey Garner [ mailto:gmgarner@xxxxxxxxxx
<mailto:gmgarner@xxxxxxxxxx> ]
Sent: Thursday, March 08, 2001 12:15 PM
To: Jonathan Thatcher
Cc: Serial PMD reflector (E-mail)
Subject: Re: Jitter work for clause 52
Jonathan,
I have a few comments on the jitter draft
you had
attached. While I did not attend the conference call this week, I
did
discuss this with my colleague, Juergen Rahn. My comments concern
the
entire draft, though I can see that the receiver portion was
already there (you indicated you had written
up the
transmitter part). I do plan to attend the meeting next week.
1) Golden PLL, Golden receiver, and receive
eqiupment in transmitter test, referred to in Figure 52-3 and lines
4-15
(approximately) on p. 357 (just above section 52.8.2). I believe it
is
appropriate to specify this equipment, as this defines how
the transmitter measurement is to be made.
If, as
indicated in the note beginning on line 9 of p. 357, these are
outside the
scope of the document, then it will be difficult to achieve
interoperability. This could happen if 2 different vendors used
different test equipment for transmitter and
reciever, respectively, one of which forced a greater burden on the
system
under
test than the other. In addition, it would
be
difficult to verify compliance if the developer/vendor of equipment
used one
set of
test equipment and the customer used
another.
Regarding the golden PLL, this is in essence
equivalent to the high-pass jitter measurement filter. Its
bandwidth should
should be equal to the breakpoint on the sinusoidal jitter tolerance
mask.
I don't know if the sinusoidal tolerance mask has been decided on
yet;
however, using as examples the ones that have been discussed in the
past,
the breakpoint would be 4 MHz for the ITU (SONET/SDH) mask (which
has flat
level of 0.15 UIpp sinusoidal jitter that must be tolerated) and 6
MHz for
the Fibre Channel mask (which has flat level of 0.1 UIpp sinusoidal
jitter
that must be tolerated. The sinusoidal jitter tolerance mask is
effectively a requirement on the minimum bandwidth of the receiver
(For
example, if the Fibre Channel mask is used,
it says the reciever must have a minimum BW
of 6 MHz
if it just tolerates 0.1 UIpp sinusoidal jitter for higher
frequencies; if
one wants to use a 4 MHz BW, the tolerance must be increased to 0.15
UIpp
for frequencies above this). By choosing the golden
PLL BW to correspond to this jitter
tolerance mask
breakpoint, this ensures compatibility of the transmitter and
receiver.
Also in the paragraph on the golden PLL
(lines 4 - 7
on p. 357), it is mentioned that there will be sufficient wander or
drift
in the system under test to result in eye
closure.
If the intent is to really talk about wander here, then this effect
is
unimportant.
Wander is low-frequency variation in the bit
timing
(zero crossings of the bit slopes). This is well below the
bandwidth of the
golden PLL (or of a receiver used in practice) and is easily
tracked.
However, it does say that the frequency draft will occur over the
time it
takes for the optical signal to traverse the fiber. If this time is
sufficiently short (I don't know what this time is),
then this frequency change would actually be
jitter.
Since it is occurring in the transmitter clock of the system under
test, I
would classify it as part of jitter generation. What is most
important in
determining whether this is jitter or wander is the time scale over
which
this occurs compared to the golden PLL time constant (1/BW).
2) For the receiver conformance test
(Section
52.8.2), I see that this is the same as what is in the D2.1 and D2.2
drafts.
My main comment here is that there needs to be consistency between
this, the
transmitter test, and the receive sensitivity measurements given in
Section
52.8.8 and the tables referenced there (Tables 52-6,7, 10,11,
14,15).
Related to this, it would be useful if a power penalty were
specified for
the sinusoidal jitter component in item 8) at the bottom of page 357
(Section 52.8.2); the usual penalty for this is 1 dB optical. On
the
consistency issue, Tables 52-7, 11, and 15 indicate that stressed
receive
senstivity is measured with 1e-12 BER at the eye center. They do
refer,
however, to Section 52.8.11 (in D2.1, which
is 52.8.2 in your document), which has the
DDJ, DCD,
and sinusoidal jitter added. In any case, my main point is that
if we define stressed receive sensitivity to
include
a set of impairments with a certain power budget at 1e-12 BER with
sampling
at the eye center, then if we add the effect
of
jitter, the BER will go up. Or, to put it differently, if the BER
is 1e-12
with all the
jitter sources present, then it would be
much lower
if we remove these sources but keep all the other impairments and
the same
power level. If the sinusoidal jitter has a
specified power penalty, then this can be included in the budget.
In
addition, it means that sinusoidal jitter tolerance can be measured
by
measuring the jitter associated with this power penalty.
Thanks.
Regards,
Geoff Garner
Jonathan Thatcher wrote:
Here is my humble attempt at writing
up the
transmit side of the jitter specs for clause 52.\As you can see,
there are a
number of places where help is needed.Will join the PMD serial
teleconference at about 15 to 20 minutes after the start.I wrote
this based
on a version of 52 that was somewhere between 2.0 and 2.1. Sorry if
there is
any confusion because of this.jonathanJonathan Thatcher
Principal Engineer, World Wide
Packets
Chair, IEEE P802.3ae Task Force
Office: 509.242.9228 Fax:
509.242.9001
jonathan@xxxxxxx