SJTP: Minutes from 01-May conference call
All,
Attached, please find the minutes from yesterday's conference
call. The details for next week's call are at the bottom. The
time and number hasn't changed.
Thanks,
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
-----------------------------------------
Conference call of the Serial Jitter Test Pattern ad-hoc
1-May-2001, 1:00pm EDT
Attendees:
Ben Brown
Jonathan Thatcher
Don Alderrou
Bill Reysen
Tom Lindsay
Gareth Edwards
John Ewen
Pat Thaler
Proposed Agenda:
Review the proposals comparison that I circulated
yesterday.
Just before the meeting, John Ewen sent an email to the
reflector. This email is referenced a few times in today's
discussion.
Discussion:
Based on comparison of proposals, we're not very far
away from agreeing on a methodology.
We haven't had a discussion on the pros and cons of
flexibility.
Without flxibility, we can't change patterns as we
find something else. However, if we can pick some
seeds right now, patterns can be generated and we will
have a solution.
Flexibility is completely orthogonal to generating
good patterns. However, this is still an important
decision.
If we put off this decision for a short time, then
there are no other differences between the proposals.
Exception could be multiple sub-patterns. To stress
the CRU, it is nessary to have at least 2 patterns,
one being the polarity opposite of the other.
If it's only a couple of seeds, they could be built
in. If it is multiple (10?), programmability would
be worth it.
Is it possible to get all the characteristics from a
single seed? Probably.
We either build a pattern with all characteristics or
allow multiple seeds with each sub-pattern that contains
all the characteristics. This allows a pattern to be run
only once to cover all the tests. Another solution is
to run the test multiple times with different seeds.
Each pass tests a different feature.
Example:
Have a "Power Pattern" and a "Jitter Pattern"
These need to be run separately.
Within the Jitter Pattern, there is a sub-pattern
A and the inverse of sub-pattern A.
If there were space for 2 seeds in programmable registers,
you should be able to run any test in the world. Assumption
implied here that 2 seeds and configurable length allows
for the perfect test.
If we can't find the perfect seed, we need to allow for
more seeds or multiple test runs. Nasty patterns can easily
be found to test at least 2 or 3 of the features we're
trying to test. Can we easily find a seed that produces
a pattern that tests them all?
We haven't seen any proof that we need flexibility. We
can find seeds today that are adequate.
There is no analysis or data that proves this. The concern
isn't so much that the pattern might not be good enough
but that it might be too stressful. A problem with the SONET
pattern is that it isn't flexible and no one can play with
it.
If we can't pick a good seed, then can we prove interoperability?
SONET is a special case because of the short scrambler.
This can result in some ugly patterns that we're not likely
to see.
We're already talking about choosing a seed that produces a
once per day pattern.
What's the cost of programmability? Depends on the
complexity.
Some have different bit-width implementations of their
scrambler so the complexity of loading seeds might be
different for different implementations. This might have
a concern for the frequency of loading the scrambler.
If we make this a multiple of 256 (for example), we'll
probably be safe. It is unlikely that scramblers would
be implemented wider than 256.
Support for flexibility comes from how comfortable people
are with the choice of a good pattern. Some don't feel we'll
get very close. Others feel we'll get close enough the first
time. We might find a pattern that is a little better at some
time in the future but how much better will it be? Would it
really be worth the complexity of adding flexibility now?
Flexibility for positive or negative is probably sufficient.
Still concerns that the pattern we start with is too
restrictive or stressful.
Run lengths of 50 using different seeds provide very
different characteristics.
We're going to have to pick a seed eventually anyways,
regardless of whether it is to be programmed in a register
or fixed in silicon. There is no straightforward way to
find a seed/pattern. The only way to do this is brute
force. How do we know we'll pick the right one? There
are probably 256 different patterns with a run length
of 50, and this is only with a fixed data input. If this
is allowed to vary, the patterns get higher?
Another concern is that there could be multiple proprietary
methods for flexibility. This might not be desireable.
What needs to be flexible?
Programmable pattern length
- A reason for doing this might effect overall running
disparity. Inverting the output for every other pass
would solve this.
- Seems to be no support for this feature
Programmable data input
Programmable seed
For inversion, either support flexibility for it directly
or via inverting the programmable seeds and data inputs.
We wanted to keep pattern length less than 8000 (k?)bits to fit
into a BERT. This would result in positive pattern of 4000
then an inverted pattern of 4000. This should not be a problem.
2 sub-patterns, each with the ability to invert, should be
reasonable.
Always invert every other pass. With 2 seeds, what's the
order? If we fix the length, we probably don't care about
the order. Let's fix this:
Seed A
Seed A Invert
Seed B
Seed B Invert
This results in 2 programmable seeds (58-bit registers).
Running disparity does not matter from time 0, but rather
from a sliding & decaying window.
This is probably not essential but reasonable.
Do we need to have programmable data? Reasons are the same:
- greater flexibility in the pattern
- same seed, different input provides dramatically
different results
- Constant data of all 0s results in more predictable
results. Varying or Local Fault reduces predictability.
Both the advantage and dis-advantage is that it makes the
selection process more difficult. The best way to "bust"
up multiple runs of disparity are to vary the input pattern.
Only allow for 16-bits to be programmable. They would be
applied repetitively based upon the width of your
implementation. Another option would be to select between
all 0s or 64B/66B encoded Local Fault (this really doesn't
increase the number of ones significantly but apparently
is quite significant based on John Ewen's results).
All programmable registers should be common between TX
and RX - no asynchronous testing.
Is the differences in results from the 0s to the LF, the
kind of difference we need? As we search for patterns, do
we need to have a different effect than this? Results from
John's simulations might help to answer these questions.
Future work:
I will put together the presentation that I intend to
make in May before next week's meeting. According to a
motion in March, this is to be circulated 2 weeks before
the May meeting. This will be reviewed in next week's
meeting and released later next week.
In next week's meeting, after the presentation review,
we will begin putting TBDs and parameters in place for
John Ewen to use in search of seeds/patterns. Thanks to
John for not refusing our request to perform this effort
for us.
Another effort we'd like to see come together, it would
be great to have some patterns available in May in hex
ascii to release to the general public at the meeting.
This would allow others to feed them into their BERTs.
We've had little luck in the past. This might mean a
lack of technical feasibility(?).
Part of the problem might be with the few people that have
10G capability. Would scaling to OC-48 be worth it?
Thanks to all for attending!
Next conference call is set for next week at the same time
and number:
CONFERENCE INFORMATION:
----------------------
* Start Date: 04/17/01 TUE
* End Date: STANDING
* Start Time: 01:00 PM EDT
* End Time: 2:30 PM
* Duration: 001 hr 30 min
* Conference Host: BENJAMIN BROWN
* Conference Name: SERIAL JITTER TEST PATTERN
* Conference Arranger: BENJAMIN BROWN
* Arranger Phone Number: (603)641-9837
PARTICIPANT INFORMATION:
-----------------------
All Participants should use the following information
to reach the conference call:
* PARTICIPANT CODE: 221497
* Toll Free Dial In Number: (800)851-1769
* International Access/Caller Paid Dial In Number: (775)324-0362
Call ended at 3:05 EDT