SJTP: Minutes from 10-April call
All,
Attached are the minutes from today's Serial Jitter Test Pattern
conference call, along with an updated feature list. Please
review for accuracy and expect to continue with the process for
next week. We'll have another call at the same time. I'll send
out a reminder with the call details later.
Thanks to all for attending.
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
-----------------------------------------
Second conference call of the Serial Jitter Test Pattern ad-hoc
10-April-2001, 1:00pm EDT
Attendees:
Ben Brown
Don Alderrou
Dawson Kesling
Jennifer Evans
Piers Dawe
Anthony Sanders
Pat Thaler
Gareth Edwards
Bill Reysen
Steve Haddock
Jonathan Thatcher
Schelto van Doorn
John Ewen
Proposed Agenda:
Review the feature list that I started last week.
Continue with Jonathan's list
Add any that are missing
Unless we're done early, I'd like to push out specific
proposals until next week so we all have a chance to
review the features and the proposals one more time.
Discussion:
"Patterns need to fit into BERT memory"
Depending on the test you're running patterns can be long
or short.
Will the same packet produce the same bit sequence on
the fibre?
The same packet will not generate same bits on the wire
because the scrambler will likely be in a different
position at the start of each packet.
"Run Lengths"
Use lower end numbers on "Run Lengths..." bullet item
Example of 10 different things can break a link. Assuming
we want to target an event to occur no more than once per
day, any one of these things should occur no more
frequently than once every 10 days.
Standard says BER of 10^-12. Designers strive for 10^-15.
Perhaps we're being more pessimistic than we need to be.
If we have 2 conditions that cause errors, if we get close
on one of them, we only break if the other is also close.
This is because most types of errors are related (?).
Long runs aren't necessarily worse than shorter runs with
low frequency transitions. These types of patterns can
occur much more frequently than these long runs.
This conversation fits under "transition density" bullet.
This is testing a different characteristic of the PLL.
Run length is 50 bits, low transition density could be
500 or 5000 bits so this is a different test pattern.
Another pattern could be a long run length followed by
many short runs - this tends towards large disparity.
Under pattern content bullet, add shift in frequency
content. Also, transition densities (high and low).
5 patterns:
1) Long run lengths
2) Long length of low transition density
3) Rapid change in transition density
low to high is more stressful
2 is a subset of 3
4) Extreme running disparity
5) Rapid change in running disparity
6) Polarity biased, stressing a particular data edge
Stresses PLL that only uses 1 clock edge, rather
than both
This could be picked up as part of number 4
"BER Measurement"
One might want to make BER curves, looking for low
bound somewhere between 10^-3, 10^-5.
MDIO allows reads at least once per millisecond.
16-bits reaches down to 10^-3, 8-bits goes to 10^-8.
This feature is not required in the standard to be compliant.
This would allow someone to characterize the link and qualify
it for the field.
This is a whole new application space.
Make this non-essential but a nice feature.
This is testing something different than looking at PLL
characteristics. Test the hardware in the lab first then
take it into the field to test the link. The problem is
that a service provider might not have control over the
hardware.
What is a bit error?
Older BERTs use blocks, and each block that is in error is
considered a single bit error.
Current counter counts bits but multiplies them by 3. This
x3 is only accurate if errors are no closer than the distance
to the taps.
Now looking at Jonathan's list:
10) Able to synchronize in presence of bit errors:
This can be impossible for a high enough bit rate.
Is 10^-5 acceptable? probably. This makes the shift contents
normally correct.
Even if we use the 64/66 coder, this level of BER should
not result in loss of sync. Even 10^-3 should get sync
eventually (in a short time) but 10^-5 is very possible.
How do we count errors:
1 bit error turns into 3
20 turns into 60 but even 17, etc., has larger affect because
of the taps.
1-10 errors is probably the range that allows any kind of
recovery and meaning to the counter
This means the worst your variation in counting is 1 order
of magnitude. If the errors are worse than this, bad
counts are really bad.
Let's count on using a block count.
14) - put this in non-essential but nice.
The agenda for next week will be to once again review our
new list then continue through Jonathan's list and add
anything we think we're missing. Once we're comfortable
with our feature list, we can compare proposals to it.
Thanks to all for attending!
Next conference call is tentatively set for next week at
the same time.
Call ended at 2:30 EDT
10-April-2001
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
* Pattern Contents
(#2,#3 & #4 from JT list)
1) Long run lengths with no transitions
44 bit lengths statistically occur every ~ 1/2 hour
48 bits occur once per day
50 bits provides the order of magnitude margin we need
2) Long run lengths of low transition density
3) Rapid change in transition density
low to high is more stressful
2 is a subset of 3
4) Extreme running disparity
5) Rapid change in running disparity
6) Polarity biased, stressing a particular data edge
Stresses PLL that only uses 1 clock edge, rather
than both
This could be picked up as a subset of number 4
* 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
This counter must have the ability to reset for a new measurement
* Ability to synchonize in the presence of bit errors
(#10 from JT list)
This should be very possible at BER of 10^-5 or perhaps
even higher (10^-3?)
For the purpose of discussion, a bit error is defined
as any error in a 66-bit block
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
Non-Essential but "nice to have"
* 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
* Stressful, but reasonable, for EMI testing
(#14 from JT list)
Not Yet Qualified:
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.