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

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@amcc.com
-----------------------------------------

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@worldwidepackets.com>
To: 'Ben Brown' <bbrown@amcc.com>, serialpmd
     <stds-802-3-hssg-serialpmd@ieee.org>

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).