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

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