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

RE: [802.3ae_Serial] From serial PMD call 11 Dec




Gair -

Most of us at 802.3ae would like to keep the stressed eye test. However,
because it is so complex, we are seriously struggling with how to
calibrate the signal (as defined in D4.0). This is the main reason (I
believe) we are looking at alternative test(s).

There is a difference between D4.0 and 802.3z in that D4.0 includes
significant additional jitter in the stressed eye. 802.3z spec'd ~0.1UI
of jitter (named DCD), whereas D4.0 requires ~0.5UI of jitter, some
being of high probability and the rest of Gaussian pdf. Were you aware
of this difference? Am I correct in my assessment?

64B66B and general instrument performance at 10G are also behind the
struggles.

The proposal I outlined (it is not really mine) is to return more to the
802.3z definition for the stressed eye and add a separate test for
jitter tolerance. Since there would be a separate jitter tolerance test,
than the need for ~0.1UI of jitter in the stressed eye should be less
important. Note - I expect there would be some jitter anyway no matter
how hard one tried to eliminate it. This stressed eye test would still
challenge Rx bandwidth and sensitivity.

Thanks for responding.

Tom
425/672-8035 x105

-----Original Message-----
From: Brown Gair D DLVA [mailto:BrownGD@xxxxxxxxxxxxx]
Sent: Tuesday, December 18, 2001 6:26 AM
To: Lindsay, Tom; stds-802-3-hssg-serialpmd@xxxxxxxx
Subject: RE: [802.3ae_Serial] From serial PMD call 11 Dec


All,

I snipped out one thread of Tom's that I wanted to discuss.  See below. 

Gair

*********

>>TAL - if we separate a jitter tolerance test from a stressed eye test,
then we should intentionally add jitter only to the former. From
Jonathan's descriptions, he is more concerned about instantaneous jitter
closure due to DDJ, and I propose that is all we do - that is, do not
intentionally add type-A DCD. The jitter that is added should be based
on
the bathtub curve as we have currently defined (assuming again that it
can
be calibrated).

(GB) We really need to step back and discuss why the stressed eye test
came
about.  Prior to GbE, independent parameter characterization, such as
your
propose, was the norm.  My perception for GbE was that it (the stressed
eye
test) gave us a concrete way to validate all of our "fancy model"
parameters
in a "real world" test that could be easily related by link designers
and
users.  With the additional complexity of the models we are having to
use
with 10GbE, I think perhaps this is even more true today.  In addition,
I
believe there is an impression that we can set individual parameter
requirements more loose (to allow designers more room to make trade
offs) as
long as we maintain the stressed eye test - because all of the tradeoffs
have to simultaneously function in the combined test.



***********************************************************************
Naval Surface Warfare Center           browngd@xxxxxxxxxxxxx           
Code B35                                        phone: 540-653-1579
17320 Dahlgren Road                       fax: 540-653-8673
Building 1500 Room 107
Dahlgren, VA 22448-5100



-----Original Message-----
From: Lindsay, Tom [mailto:tlindsay@xxxxxxxxxxxxxxxxxxxx]
Sent: Tuesday, December 18, 2001 2:13 AM
To: stds-802-3-hssg-serialpmd@xxxxxxxx
Subject: RE: [802.3ae_Serial] From serial PMD call 11 Dec



RE: [802.3ae_Serial] From serial PMD call 11 Dec

Piers - thanks for all the good notes. I have tried to collect some
thoughts
and have responded within. See responses marked with ">>TAL - ".
Tom

-----Original Message-----
From: piers_dawe@xxxxxxxxxxx [mailto:piers_dawe@xxxxxxxxxxx]
Sent: Monday, December 17, 2001 10:29 AM
To: stds-802-3-hssg-serialpmd@xxxxxxxx
Subject: [802.3ae_Serial] From serial PMD call 11 Dec


More food for thought.  Progress comes in very small steps - here, we
may
have clarified the meaning of DCD and the need for a lone bit pattern -
but
we have far too little test results to base firm decisions on.  We seem
to
be many weeks away from "technical feasibility" of the test procedures,
and
without that we can't finalise spec numbers such as sensitivity or
jitter.

Creating stressed eye
---------------------
Steve reported that with coax cable, he achieved the right amount of ISI
with about 12 ps DCD, more than he needed.  If this is generally the
case,
could use a lesser amount of coax cable to create the DCD then a filter
to
increase the ISI.

>>TAL - simply for my understanding - by ISI, are you are referring to
amplitude closure? When I hear ISI, I think of it as a cause of possibly
both amplitude closure and jitter.

However, one may get more practical and repeatable measurements by
putting
the ISI in one test and the jitter in a different one.

>>TAL - this is my current preference. It obviously does not solve the
jitter measurement problem, but should help the stressed eye
calibration.

To create a slow but not jittered eye, filters in the range 3-4 GHz may
be
required.  Unusually, we would be using such a filter with frequencies
much
above the filter's bandwidth, and the group delay may not be well
controlled
above say twice the bandwidth.  Bad group delay could introduce jitter
again.  Cascading two or three 7.5 GHz filters might create ISI and
pulse
shrinkage in the right ballpark - would anyone like to try?

>>TAL - with the goal of a stressed eye test with NO intentional jitter,
I
did a little analytical work on this. Theoretical 4th order filters that
cause ~3dB vertical closure (for example) lead to a very small amount of
DDJ, less than I expected. Real filters, of course, may cause more DDJ.

Measurement
-----------
Can we make more use of the scope rather than the BERT, as it may have
less
distortion?
Can we make more use of the algorithms built into the scope?  Can we use
the
"% in +/-1,2,3sigma" readout?

Lone bit pattern
----------------
It appears that to measure ISI in the stressed eye we haven't found an
alternative to the "lone bit pattern" concept, but the
64-zeroes,1,0,64-ones,0,1..... pattern has an extremely low transition
density.  While this might not be a fundamental problem, we do show a
golden
PLL in fig. 52-13 so  a more reasonable pattern is desired.  A pattern
length which is a multiple of 66 bits may be desired.
One approach is to introduce 1010... sequences to raise the transition
density.  Another is to shorten the runs, e.g. 000010111101 repeated 11
times is 132 bits (2, 66 bit blocks) long).  Can we measure A_N and A_O
of
fig. 52-14 well enough with either of these?  Do we get acceptable
calibration by calibrating with a lone bit pattern and measuring with a
mixed frequency pattern?

>>TAL - if we are only calibrating a test setup, why are we bound to a
pattern based on 66 bits? Although I think runs of 64 are longer than
necessary, but runs of 4 may be a little short with so much ISI. 05FAh
is
extremly simple to setup in a BERT (runs of 6). I have no strong
opinions on
this.

>>TAL - rep rates for such short patterns are well above the golden PLL
response times, so I would not expect any PLL response. Same for pattern
dependencies. As such, presence of a Golden PLL for calibration with
short
patterns seems irrelevant...

>>TAL - ...which gets into your last issue - correlation between cal and
test patterns. I suspect we won't know much about this until we spend
some
serious lab time with real patterns and real golden PLLs... Note that I
am
generally a fan of cal with lone bit patterns, if we can make it work.

Metric for signal amplitude
---------------------------
Our metric is OMA on a square wave, equivalent to A_N in fig. 52-14.
Oscilloscopes may not measure well on square waves [After the meeting:
there
is "V amplitude" = Vtop = Vbase where Vtop|base is the most prevalent
value
in the upper|lower portion of a pulse.  Needs repetitive signal?].  They
have two algorithms built in: "Eye amplitude" which is the difference
between the mean one and mean zero in the center 20% in time of an eye
diagram, and "Eye height"  which is
(mean "one" - 3.sigma) - (mean "zero" + 3.sigma).  The latter is too
pessimistic where ISI is present.  Other algorithms could be used, if we
knew what we wanted.

>>TAL - this topic relates to your other thoughts about not using
specific
test patterns but general traffic. I am certainly open to ideas on this,
but
I fear doing something too radical at this point (yet maybe such is
necessary). My larger concern is that I would want to be sure the tests
align with the specs and that the specs align with the modeling tool. As
we
discussed awhile back, there is currently some discrepancy in the tool
involving mask scaling.

Jitter calibration
------------------
We still cannot calibrate the jitter bathtub from the BERT.  One or
other of
the pattern generator and the error detector adds significant data
dependent
jitter.  This cannot be calibrated out in any convenient general way
like
root-sum-of-squares because it could combine constructively or
destructively
with the data dependent jitter of the device under test.  One
hypothetical
way forward would be to never try to measure "W" in a calibrated way,
but
apply SJ to the desired W.  I suppose this is useful when creating the
stressed eye if we think that the "W" from the pattern generator is
tolerable; this way we would avoid the "W" in the error detector.
[Further
thoughts while writing these notes: But we still need to calibrate the
transmitter under test jitter bathtub measurement, or drop the "shall"
from
this test.  Assuming the pattern generator has no "W" and calibrating to
SJ
seems too optimistic.]

>>TAL - my 5-dimensional matrix had only to do with jitter calibration
(and
measurement). Other than jitter, it really did not intend to deal with
setup
of a stressed eye. I basically like the jitter measurements we have
written
into the standard (bathtub curve, etc.), and I am still hoping that we
can
find a way to compensate for equipment inadequacies.

Discussion of Juergen's jitter measurements
-------------------------------------------
See email thread.  Juergen gave some ballpark estimates of ageing margin
in
jitter terms: e.g. 0.1 UI margin, or where SONET/SDH require 0.15 UI
jitter
tolerance, expect to see 0.3 in the lab.  He hopes to continue his
jitter
measurements.

What does DCD mean?
-------------------
DCD stand for duty cycle distortion.  More precisely, we have two
competing
definitions:
A.      The average pulse shrinkage of isolated ones, or pulse
lengthening
of isolated zeroes.  This can be determined with an oscilloscope, either
with a square wave (not 1010 - too pessimistic) or on an eye diagram, by
comparing the average time at which the rising edges cross 50% and the
average time at which the falling edges cross 50%.  As the position of
the
edges is pattern dependent, these two measurements would give slightly
different results.

>>TAL - FC bases this on mixed data crossings as you describe below.
Based
on fractional UI. This is obviously very difficult to measure on an eye
when
other jitter exceeds the DCD.

B.      Twice the amount by which the shortest isolated symbol in a
sequence
is shorter than the nominal symbol period.  This could be determined
with a
time interval analyser or a scope triggered on the pattern.
In either case we don't seem to care whether it is one or zero which has
shrunk, and we quote a positive number.
Fibre Channel follows definition A.  My scope instructions describe the
eye
diagram method, and also a "duty cycle" measurement for a square wave.
In
Gigabit Ethernet, and considering the way the Gigabit link model works,
it
appears that definition B is more relevant, at least when using the
8B10B
code [separately, Jonathan pointed out that type A distortion will
affect
the receiver's slicing level].
Petar suggested we should consult the official IEEE dictionary (IEEE
100,
The Authoritative Dictionary of IEEE Standards Terms) which is not on
line
(http://standards.ieee.org/faqs/Std100.html ).  Dear reader, if you have
this
book, is Duty Cycle Distortion defined there?
On the call it was felt that 6 ps of average shrinkage would be
excessive.
If that is the consensus view, we could keep the 6 ps, if that's a
reasonable amount, and change the name to "instantaneous pulse
shrinkage" or
similar.  Or, we could keep the name, use definition A, and reduce the
amount, probably to an insignificant amount so that we would not have to
create it in the stressed eye generator.  The prospect of managing both
types of pulse shrinkage was viewed with disfavour; things are
over-complicated already and we were having this discussion with a view
to
simplification!

>>TAL - I'm sure that like most, I care less about what has been done
historically than what is appropriate to do now. I also care a lot about
what is doable with reasonable effort and expense.

>>TAL - if we separate a jitter tolerance test from a stressed eye test,
then as I mentioned near the top, I propose not intentionally adding any
jitter to the stressed eye test.

>>TAL - if we separate a jitter tolerance test from a stressed eye test,
then we should intentionally add jitter only to the former. From
Jonathan's
descriptions, he is more concerned about instantaneous jitter closure
due to
DDJ, and I propose that is all we do - that is, do not intentionally add
type-A DCD. The jitter that is added should be based on the bathtub
curve as
we have currently defined (assuming again that it can be calibrated).

Upper cutoff frequency test
---------------------------
Petar's colleagues are working towards the receiver upper cutoff
frequency
test, but couldn't report feasibility (or lack of) yet.

>>TAL - no experience on this. It's been around since 802.3z, so I'm
surprised there isn't more familiarity. It's also in FC (albeit with
electrical signal combining).

Status of golden PLL
--------------------
Availability of clock recovery unit for "golden PLL" use.  There should
be
one soon, with 4-5 MHz jitter transfer bandwidth.  We don't yet know how
much jitter it will generate (or filter out).  Clock recovery units can
create pattern-dependent jitter.

>>TAL - of course, measurements also require golden filters, golden
channels, delay filters, etc. Of these, I agree that a truly golden PLL
may
be the biggest challenge, although all are necessary with their
appropriate
properties.

Next phone meeting
------------------
The next PMD teleconference is tomorrow at the usual time and
coordinates:
        4:15 pm GMT = 17:15 CET = 11:15 am EST = 8:15 am PST, Tuesday
        +1(816)650-0631  Access code 39209
The main topic will be optical testing again.  Note this will be the
last
teleconference before the holiday season.  The series can restart on 8
January, just a few days before the ballot closes and the next
face-to-face
meeting.

Piers