SJTP: Minutes from today's teleconference
Hi,
Our first conference call was held today. Attached are the
minutes. I've also attached a note from Jonathan with a
list of features that were addressed today. I've also
attached a list of features that I've started organizing
to use as our "ideal feature list". Feel free to comment
on any or all of these notes.
Our next call will be next week at the same time:
Tues., 10 April, 1:00pm EDT (6:00pm BST, 10:00am PDT)
I'll provide the phone number as the time gets closer.
Thanks for a great first call.
Ben
--
-----------------------------------------
Benjamin Brown
AMCC
2 Commerce Park West
Suite 104
Bedford NH 03110
603-641-9837 - Work
603-491-0296 - Cell
603-626-7455 - Fax
603-798-4115 - Home Office
bbrown@xxxxxxxx
-----------------------------------------
First conference call of the Serial Jitter Test Pattern ad-hoc
03-April-2001, 1:00pm EDT
Attendees:
Ben Brown
Piers Dawson
Gareth Edwards
Tom Lindsay
Don Alderrou
Bill Reysen
Peter Olin
Pat Thaler
Proposed Agenda:
Review the Feature list provided by Jonathan Thatcher along
with the additional features submitted by Dawson Kesling,
Tom Lindsay and Piers Dawes and others added on the fly
Modify, Prioritize, Clarify these features until we all
agree on what an ideal pattern should provide
I don't want to talk about a particular proposal at this
meeting. I'd rather focus on an ideal solution's features
then let everyone have a week or so to digest these
features. If after a week of looking at these things
we all still agree to them, then we should look at the
individual proposals and see how they fit in with the
features we've agreed to.
Discussion:
Piers doesn't feel we need to make this mandatory as we'd
be putting unrealistic restrictions on implementations.
We can still talk about what a good pattern should be,
regardless of whether it turns out to be mandatory.
JT's list:
1) How short is short?
at least 2-4k
10k is probably not out of the question
1MByte might be possible
1 Mbit, 4 Mbit
the original PRBS was chosen because it already existed
in common BERTs
8 Mbits in Agilent 10G BERT - Model # 71612B
2) 50% +/- 5% over total pattern
Make this a lower priority because it doesn't need to be
perfect.
3a) Longest run length
65 bits, once in 100 years, well below 10^-12 BER
choose 1-2 orders of magnitude worse than our expected BER
what is once per day?
44 is once per 2000 sec (10^-12 BER)
48-50 is once per day
We could chose low 50s
With 58 bit scrambler, hard to get anything longer than 58 bits
Multiple seeds available to get low 50s in 58 bit scrambler
3b) Get multiple bursts or shorter run lengths close together
Swap between short bursts of 1s then short bursts of 0s
Factors that affect a receiver:
Sparseness of transition makes PLLs wander, resulting in
jitter.
Long runs without transitions then run with many transitions.
Long run of disparity affects the ac component of the signal
but not the pll (?) If poor ac performance, results in jitter.
If a PLL only looked at rising or falling, it might be more
sensitive to all 1's or all 0's. This is difficult to
do with a single seed but is much simpler with multiple seeds.
Patterns are not even. They tend to wander slowly in one
direction then return quickly. They tend to go far positive
then back to 0 or slightly negative. They infrequently go
as far positive as negative or vice versa.
Use statistics to keep us realistic. Don't stress it with a
pattern that will never occur.
Memory is depth of capacitor, not forever.
XAUI CJPAT
If a pattern with low trasition denisity (5 one, 5 zeros) thru
a long link with ISI then the pattern transitions to high
density, the crossings move on the scope.
This is good for 8b10b. With scramblers, you get the same thing
with long run lenghts followed by normal, random scrambled data.
The important thing to consider is the time constant of the PLL
which can be thousands of bits.
With 8b10b, this is possible. With scrambled data, this is
extremely improbable. We can take great advantage of the fact
that this is scrambled code. Also, a particular data pattern
that might fail on one pass would likely be okay the next
time because the scrambler would be starting in a different
location.
4) Part of 3a & 3b discussion
4a Long run lengths match those in #3
4b use sparse patterns followed by dense patterns
4c try to match patterns in one direction with the other direction
5) OMA & extinction ratio have 3 distinctly different philosophys.
* FC: use square wave (5 1s, 5 0s) , low noise, settled state
- this has been updated to be similar to SONET using mixed data
* SONET: can't force special data so use normal data from the box
* other: really use the asymptotes (?)
Is there debate on meaning of OMA or just the test methods?
There is a divergence in the numbers between what a FC
engineer would measure and what a SONET engineer would measure.
Either method works but we need to be clear so we all measure
the same thing.
Have transmitter send square wave to make measurement simpler.
Receiver need not be able to capture them.
A pattern not divisible by 66 might be very difficult.
Overspecification might make this impossible for some
implementations. If recommendation is 4 1s, 4 0s square
wave and an implementer uses 5 1s, 5 0s, the process will
not necessarily be wrong.
If different methods are chosen and well documented, the
results should be comparable.
Could we change the definition of extinction ratio? We'd
probably have to change the spec to match our new definition.
All tests can be done with 1 of 3 patterns:
low frequency square wave
high frequency square wave
"random" data
Description of fibre channel rise and fall measurement tests:
vertical histograms to get "1" and "0"
horizontal histograms to get "rise" and "fall"
This is great on paper but seems awful complex
802.3ae should probably not do it this way
Some discussion on the model and masks.
We could pass the mask but fail the rise time.
Rise time is required to fit into the model.
This discussion is more methodology than pattern
specific so will be moved to Piers's call.
6) okay (for basic tx to rx patterns, perhaps not for square waves)
7) Use a large enough error counter to track a large number of
errors in a short time.
We're simulating a pattern that should very rarely occur so
you either get errors or don't get errors. It shouldn't vary,
at least in the lab, by BER.
Certainly the counter should stick at max value.
Make TBD = 10^-8
- 8 bit counter read once per second with a counting
method of tripling the errors
- Read it more often to measure higher BER
This is low priority or even kicked off the list.
This is as far as we got through Jonathan's list
The agenda for next week will be to continue through this
list. Once we have this list understood and prioritized,
we can start comparing particular proposals to this list.
Thanks to all for attending!
Next conference call is tentatively set for next week at
the same time.
Call ended at 2:25 EDT
Subject: RE: Let's get started
Date: Tue, 27 Mar 2001 18:31:32 -0800
From: Jonathan Thatcher <Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx>
To: 'Ben Brown' <bbrown@xxxxxxxx>, serialpmd
<stds-802-3-hssg-serialpmd@xxxxxxxx>
Regarding the question:
"What do you think are the most important features of a jitter test
pattern?"
This is what I remember from a variety of meetings plus a couple of my own:
1. Relatively short in length (can be loaded into BERT memory).
2. Has nearly 50% transition density (+/- tolerance TBD).
3. Contains long run lengths
3a. Longest length (TBD)
3b. Rapid trends towards large disparity (TBD).
4. Stresses the PLL clock recovery (TBD). Combinations of:
4a. Long run lengths
4b. Phase transitions
4c. Polarity biased transitions (some PLLs only look at rising or falling
edges)
5. Able to create very short patterns for some optical tests (e.g. OMA or
E/R).
6. Able to run in loop back (need independent Tx and Rx pattern generators)
7. Able to count "down" to BER rate of TBD. (10e-3?)
8. Able to reset counter
9. If two counter registers are required (depends on the TBD in # 7 above),
one must be slave to the other (slave register loaded when the master is
read, only).
10. Able to synchronize in presence of bit errors (BER TBD).
11. Pattern flexibility.
12. Technique works for both the WAN and LAN phy (WAN must include the A1/A2
sequence; LAN must not).
13. TBDs are based on an probability of occurrence equal to once per day for
single bit errors.
14. Stressful, but reasonable, for EMI testing (e.g. no short patterns; see
#1 above).
I would like to note that number 5 above was not shown in the Ewen/Thatcher
presentations in March due to information overload. This is simply
accomplished by turning on and holding on the seed reload active. Easy.
I think that I mentioned in my talk that number 10 could potentially be
accomplished by use of the error rate counters.... If not, that is one way
to define and potentially select the synchronization BER.
I would like to note here that I feel very strongly about # 11. I would
definitely write a TR against the draft if we did not do this. I have zero
(yep, read that 0) confidence that we will select the ideal pattern(s) in
the next six months. In short, I believe there is a very high probability
that some (or all) of the TBDs above will change as we get experience in the
field. We definitely have history supporting this.
Number 14 is not strictly required since this could be done with real data.
But, as many of us have already learned on the test field, EMI measurement
is already a difficult to repeat exercise. It is nice to remove as many of
the random variables as possible. This is, therefore, not required. But, it
would be nice.
jonathan
03-April-2001
Here's my current cut at the features of an ideal pattern:
High Priority
* A Pattern needs to be short enough to fit into BERT memory
(#1 from JT list)
MAX memory depth is 1 MByte
TYP memory depth is 64-128 kByte
Pattern length should be (much?) less than this
* Run Lengths to cover the following
(#3 & #4 from JT list)
No transitions
44 bit lengths statistically occur every ~ 1/2 hour
48-50 bits occur once per day
50-55 bits provides the order of magnitude margin we need
Rapid trend towards large disparity
shorter run lengths of same value grouped together
Polarity biased
Emphasizes a particular clock edge over time
These patterns must be "inverted" to test opposite level
* Ability to generate and check the pattern in the same device at
the same time
(#6 from JT list)
Implementers should not use the same logic for both generation
and checking, eliminating any possibility of a loopback test
* Error counter attributes
(#8 from JT list)
The counter be sticky at max value
Ths counter must have the ability to reset for a new measurement
Medium Priority
* Ability to generate low and high frequency square wave patterns
(#5 from JT list)
This allows for transmitter measurements such as OMA and E/R
A receiver need not be capable of capturing these patterns
Low priority
* The transition density should be approximately 50%
(#2 from JT list)
Variation of up to +/- 5% (or more?) is acceptable
* Ability to measure the BER "down" to a particular value
(#7 & #9 from JT list)
The existing 8-bit counter in the spec covers 10^-8 BER
when read once per second.
To detect higher BERs, this could be read more often or
an implementation could provide a wider counter
Not Yet Qualified:
10. Able to synchronize in presence of bit errors (BER TBD).
11. Pattern flexibility.
12. Technique works for both the WAN and LAN phy (WAN must include the A1/A2
sequence; LAN must not).
13. TBDs are based on an probability of occurrence equal to once per day for
single bit errors.
14. Stressful, but reasonable, for EMI testing (e.g. no short patterns; see
#1 above).