CJPAT for testing XAUI receiver and transmitter?
XAUI folks -
I have had a long-standing action to initiate discussion of the item
that Anthony listed, per his email dated 2/20/01 (re-listed below):
Section 6.5.1; Use of CJPAT for compliance testing
of (XAUI) receiver and transmitter.
1.
Does this requirement create too much restriction on the implementor and
testor?
2.
Is this requirement necessary to guarantee interopability between devices?
3.
Is the current jitter specification correct, for CJPAT or K28.5 compliance
testing?
To begin, let's go back to some Fibre channel history.
Fibre channel (FC) understood that CDRs track low frequency jitter,
and that including this effect in the specifications could ease requirements
on clock oscillators (lower cost designs tend to exhibit low frequency
random jitter), serializer (serdes, same advantage) designs, and switching
power supplies, layouts, bypassing, etc. With all this in mind, all FC
jitter output specifications include the effects of a high-pass filter
(to suppress the significance of low frequency jitter) to emulate CDR tracking.
FC also realized that, due to frequency content, long complex patterns
cause phenomena that are not observed with short patterns - data dependent
jitter (DDJ, a form of deterministic jitter) can have extreme ranges of
frequency content from well below to well above the CDR corner frequency.
Effects are usually seen in both transmitters and receivers. Since such
long complex patterns (such as CJPAT) can exist in real systems, they must
be included somewhere in a set of specifications for a standard.
Some observations:
-
High pass filtering (HPF) is appropriate for the reasons given above. If
HPF is used, then (at least in some test methods), HPF will naturally also
be applied to DDJ.
-
Without HPF, due to transmitter interactions, long complex patterns usually
result in worse pk-pk DDJ output than +/-K28.5s, although differences are
typically <10%.
-
With HPF, I have observed that CJPAT-type patterns can increase pk-pk DDJ
by more than 50%. However, when considering equivalent (bathtub curve-fitted)
deterministic jitter, this increase will be somewhat reduced in relation
to the amount of random jitter present.
-
In any case, HPF emulation implies that CDRs will have more trouble with
CJPAT than +/-K28.5s, and I have observed this in the lab with CJTPAT.
-
Jitter budgeting must be based on long patterns, since they are more challenging
and represent likely scenarios in real systems. However, this still leaves
open the debate on test methods, data patterns, and jitter test limits.
That is, it may be possible to have jitter test limits that are different
than the jitter budget.
Now, for the debate - assuming that HPF is used (do we want to debate
this one?), data pattern options are:
-
Jitter output
-
Short pattern
-
Set tighter test limits to anticipate greater jitter output so that long
patterns still stay within the budget.
-
The amount of tightening will take some thought, and will be a function
of random jitter, etc.
-
Long pattern (CJPAT)
-
Set test limits based directly on the budget.
-
Jitter/signal tolerance
-
Short pattern
-
Set test conditions worse than the output jitter budget to anticipate the
receiver's response to long patterns.
-
The amount of increase will take some thought and will be a function of
random jitter, Rx bandwidth, etc.
-
Long pattern (CJPAT)
-
Set conditions equal to output specs, which in turn are based directly
on the jitter budget.
4 combinations exist from above. My opinion is probably obvious: use long
patterns for ALL jitter budgeting and specifications in the standards.
-
Using the same pattern for everything provides a self-consistent set of
specifications, and making it a long pattern helps ensure that real mechanisms
in real systems are flushed out.
-
The first role of the standard should be technical rigor - ahead of simplicity.
-
Let test simplification be an option to those implementing the standard
- at their own risk and benefit. Specifically, leave the interpolation/extrapolation
required with short patterns to those who truly understand their own products
and are interested in simplifying their test environments. They are free
to do so.
-
The standard does not have to deal with the non-trivial task of determining
relationships between a jitter bugdet and test limits across a range of
technologies and products yet to be developed.
My opinion deals with the first 2 questions under Anthony's listing above.
The 3rd question is yet another topic for the group.
I encourage the debate to continue.
Thanks, Tom Lindsay
Vixel
425/806-4074