jitter tolerance and jitter generation discussions
Rohit,
There has been a fair amount of discussion over the last few days of jitter
generation, jitter tolerance
and the frequency content of the jitter. I am attaching the email thread below,
where you had referred
to my having mentioned that the use of sinusoidal jitter is just for testing
purposes and is not a real-life scenario
(in the 2nd email in the thread). I want to clarify that point, and also
emphasize that (1) in specifying jitter generation (at the
transmitter) it is necessary to specify the frequency of the jitter (by
specifying a high-pass jitter measurement filter) and (2) in specifying jitter
tolerance it is also necessary to specify the frequency of the jitter being
tolerated. Some of the discussion below was included in an earlier email, but
most is new.
The point I was making is that the use of sinusoidal jitter in a jitter
tolerance
test gives conservative results compared to, say, Gaussian jitter or uniformly
distributed jitter. The reason for
this is that if you look at a sinusoidal probability density (to obtain the
sinusoidal density, start with the density for
a uniformly distributed random variable, x, distributed between -A and +A; make
the change of variable y=A*sin(pi*x/(2*A)) (y is distributed sinusoidally
between -A and +A); and calculate the density for y; you find that most of the
probability mass for
y is concentrated near y = +A and y = -A. This makes intuitive sense; if the
jitter is oscillating sinusoidally between +A and -A, it spends comparatively
more time at the extremes because the sinusoid varies more slowly near the
extremes (i.e., the eye closure is larger a greater fraction of the time than it
is smaller). Based on this, applying sinusoidal jitter to a receiver
overestimates the power penalty compared to other distributions (for the same
peak-to-peak and the same frequency content).
Having said that, the frequency content of the jitter is important. This is
because jitter having frequency content less than the bandwidth of the PLL
results in less power penalty as the PLL tracks it. A receiver can tolerate
larger amounts of jitter as the jitter frequency decreases below the PLL
bandwidth. This is the reason the jitter tolerance masks are flat for
high-frequencies and have slope of -20 dB/decade for frequencies below a
breakpoint; the breakpoint represents the PLL bandwidth. Of course, this is
only the tolerance requirement; a clock recovery circuit can have a higher
bandwidth if desired.
The above is also the reason jitter generation is measured with a highpass
filter. If we take a clock recovery circuit and apply jitter, the PLL error
signal (essentially the sampling offset between the incoming signal and the
recovered clock, or, eqivalently, the PLL buffer fill) is equal to the input
phase signal filtered by a high-pass filter whose breakpoint is equal to the PLL
bandwidth. You can think of the high-pass jitter measurement filter as the
"golden PLL" used to make the jitter generation measurement.
For SONET and SDH, a number of breakpoints and measurement filters have been
mentioned. The SONET jitter tolerance mask has 3 flat levels: 0.15 UIpp, 1.5
UIpp, and 15 UIpp. For OC-192, there are 3 breakpoints: 4 MHz, 20 kHz, and, in
the newest GR-253 (Issue 3, September, 2000), 296 Hz. I will explain why there
are 3 levels and breakpoints; however, only the lowest level (0.15 UI) and
highest frequency breakpoint (4 MHz) is relevant here (I will also get to the 12
kHz shortly) (some of this I mentioned in earlier email, but some is new).
A SONET or SDH interface must tolerate jitter; however, because a SONET or SDH
signal can traverse multiple regenerators, jitter accumulation must also be
controlled. This means that there is a jitter transfer requirement for a SONET
regenerator. Often, one wants to use a transfer bandwidth that is narrower than
would be obtained by a clock recovery circuit. One does this by having a
second, narrower band PLL following the clock recovery circuit. In the above
tolerance mask, the 0.15 UIpp flat level and 4 MHz breakpoint represent the
jitter tolerance and minimum bandwidth of the clock recovery circuit. By jitter
tolerance, I mean that the 0.15 UIpp should produce no more than a 1 dB optical
power penalty. The 1.5 UIpp flat level and 20 kHz breakpoint represent the
jitter tolerance and minimum bandwidth of the second PLL, whose main purpose is
to control jitter accumulation. Finally, the 15 UIpp level is totally
artificial; it arose when the SONET specs were first developed to make things
easier for the test sets. The large amplitde jitter with frequencies much lower
than the 2nd PLL bandwidth is tracked by both PLLs; there is nothing gained by
making test sets generate this jitter. The final breakpoint of 296 Hz was added
comparatively recently (previous issues of GR-253 had the 15 UIpp flat level
without this breakpoint). The sloped portion from this breakpoint to the 10 Hz
frequency (where the amplitude is 444.6 UIpp), resulted from recent work in ANSI
committee T1X1.3 to connect the SONET jitter tolerance mask to SONET wander
tolerance masks (for now, I will omit the details of where 444.6 UIpp comes
from; but note that this corresponding amplitde is the same in units of time for
CO-192, OC-48, and OC-12 in GR-253). In any case, this 3rd breakpoint does not
represent the bandwidth of any equipment; it was merely the result of an attempt
to connect jitter and wander tolerance masks.
The above is all background; however, for 10 GbE WAN PHY there are no
regenerators and, presumably, no second, narrower BW PLL. Therefore, the
relevant breakpoint for sinusoidal jitter tolerance is 4 MHz, and the relevant
jitter to be tolerated at frequencies above 4 MHz is 0.15 UIpp. (In the Fibre
Channel spec, the level is lowered to 0.1 UIpp, while the
-20 dB/decade sloped portion stays the same; the breakpoint therefore moves to 6
MHz.).
All the above pertains to jitter tolerance of the receiver. For the
transmitter, we are interested in jitter generation. Because we only have a
single link (i.e., no regeneration and therefore no need to worry about jitter
accumulation), the relevant BW for the highpass jitter measurement filter here
is 4 MHz and the relevant peak-to-peak jitter generation is 0.15 UIpp. The 12
kHz bandwidth mentioned in some of the emails is the high-pass measurement
filter for OC-48 and below, but was an attempt to guarantee interoperability
between what were called Type A and Type B regenerators (Type A used wider
bandwidth clock recovery circuits and could tolerate more jitter; Type B had
narrower bandwidth clock recovery circuits. It was necessary to limit the
jitter generated by any regenerator to allow for the possibility for the next
regenerator in the chain being Type B). Here, we don't have Type A and Type B;
all the clock recovery circuits, if designed to meet the tolerance requirement
above (with the 4 MHz breakpoint) would tolerate 0.15 UIpp of jitter generated
when measured with a high-pass jitter measurement filter with 4 MHz bandwidth.
(Note that the latest GR-253 uses a 50 kHz high-pass measurement filter for
OC-192, while keeping the 12 kHz for OC-48 and below; my understanding is that
this was still an attempt to allow for Type A/Type B interworking).
Regards,
Geoff Garner
"Rahn, Juergen (Juergen)" wrote:
> Hi,
> The issue is that we need to know either a PLL that is used as reference or
> a related transmitter oscillator noise and its spectral behavior. The other
> effects (and this was I tried to indicate are of a much higher frequency so
> irrelevant for a PLL that can cope with a scrambled signal. The clock noise
> however is relevant for the PLL. For this also test equipment is present,
> and this is by far not able to generate such high amplitudes. (Also no
> system can cope with such high jitter in the domain indicated). There are
> physical limitations that are valid independent if an equipment is called
> ETHERNET or SONET. I am in particular not of the opinion that a receiver
> that can cope with more jitter is automatically cheaper that a jitter that
> is used with less jitter (may be the opposite is true). So following this is
> would like to separate things out, limiting the jitter that is relevant for
> clock recovery from that which only gives penalty.
> Regards Juergen Rahn
>
> ----------
> Von: Rohit Mittal [SMTP:RMittal@xxxxxxx]
> Gesendet: Mittwoch, 21. Februar 2001 23:08
> An: Rahn, Juergen (Juergen)
> Cc: 'Tom Lindsay'
> Betreff: RE: Package on jitter
>
> Rahn,
> A thought struck me. Is it possible to compare the sonet and
> ethernet jittern tolerances and see which is worse? For instance, can an
> ethernet tolerant PLL fail Sonet or vice-versa.
>
> Sonet gives tolerance in terms of frequency spectrum. Assuming that
> low frequency jitter (ie. 1.5UI and 15UI) is all within the Receiver PLL
> BW. Then we are left with .15UI jitter at all the higher frequencies. What
> will be the equivalent jitter in time domain. That is the big question?
>
> I believe ethernet's requirements of a PLL being capable of handling
> .7UI jitter (some DJ and some RJ) is much closer to real life than Sonet. As
> Geoff Garner mentioned sinusoidal jitter is just a means to do testing but
> is not a real life scenario.
>
> I think this will help us realize if we really need to specify both
> an ethernet like jitter complaince testing or a Sonet like testing for
> 10gigE PMD.
>
> -----Original Message-----
> From: Rahn, Juergen (Juergen) [ mailto:krahn@xxxxxxxxxx
> <mailto:krahn@xxxxxxxxxx> ]
> Sent: Wednesday, February 14, 2001 8:20 AM
> To: '802.3ae Serial'; 'DAWE,PIERS (A-England,ex1)'; Rahn, Juergen
> (Juergen)
> Cc: Garner, Geoffrey M (Geoffrey); Stassar, P J J (Peter)
> Subject: AW: Package on jitter
>
> Hi,
> please receive my package on jitter that I intended to be available
> at the
> Jitter meeting, however the reflector did not let it through.
> So I converted it to Word and may be it can still be of some help.
> As a consequence I see two main questions , and those are
> 1. What should the bandwidth of the PLL be (in line or
> different to
> ITU)
> 2. What is the allowed penalty (for jitter together with path
> effects
> in ITU terms)
> Kind regards Juergen
>
> <<Difference in Jitter definition of ITU and IEEE 10G
> initiative.doc>>
>