SJTP: Minutes from today's conference call
All,
Attached are the minutes from today's meeting. Also, I've
updated the presentation. Please review thoroughly.
No call next week. See you all at the meeting!
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@amcc.com
-----------------------------------------
Conference call of the Serial Jitter Test Pattern ad-hoc
15-May-2001, 1:00pm EDT
Attendees:
Ben Brown
Pat Thaler
Tim Warland
Piers Dawe
Jennifer Evans
Don Alderrou
John Ewen
Bill Reysen
Proposed Agenda:
Discuss the process for including a comment into the
data base and just what that comment will consist of.
Continue putting in place the TBDs that will allow John Ewen
(and others?) to start looking for seeds to generate the
patterns.
Discussion:
Appropriate comment filler doesn't yet exist. We do need to
have a place holder in the comment.
Comments do exist against the test patterns but it might be
nice to have a specific one.
As an editor a comment can still be added to the data base.
How do we write the text?
Once we know what is there, Pat is willing to write the
text for clause 49. Clause 45 will need some words.
Clause 52 work is not major at all. Clause 52 has decided
on what to do for 8 or 9 of the 10 tests. There are a few
references to Clause 49. Word smithing should be straight-
forward.
Should we allow the editor to make the necessary changes or
be specific? In what cases, does one want to describe what
patterns to use for the test? The PCS test pattern might be
acceptable while other patterns might also be acceptable.
Piers will bring info for Clause 52 to St. Louis.
We need to resolve this early in the meeting next week.
Open Items:
* Data variability
* Run Lengths: ~50
* What the pattern looks like afterwards including:
* transition density
* running disparity accumulation
* frequency change
* WAN pattern
Is it necessary to use the PCS layer?
It is the easiest to do and use the same implementation.
It is easier to generate using 66-bit blocks than any
other way since existing circuitry already knows how to
do this.
It depends upon where you are. If you have a PCS, it is easy
to use it. If you don't have a PCS, it is very difficult.
That's why it is desireable to use multiple patterns for
each test, one for system level and one for component level.
What happens if you somply left 10GE operating in normal
operation mode. As for SONET, data is irrelevant.
People wanted repeatability and guarantee long runs that
may not occur frequently.
Really only want something that is easy for the PCS to generate.
Wanted predictable patterns.
Does it really need to be this way?
Yes, if you want to capture or generate with a BERT.
This way, the BERT doesn't need to know anything about
64B/66B encoder.
The pattern length is divisible by 8 for those BERTs that
need pattern lengths like this.
Do these repeatable patterns really get you that much further?
Have you taken the randomness out of the pattern and will that
affect the results?
If the pattern is repeatable, measurements should be the
same on every pass. If the pattern isn't repeatable,
multiple uncertainties affect the result. (convolution)
One of the patterns is pseudo-random in 8448 but we haven't
yet defined the seed. Another class of pattern might be the
maximum run length or transition densities.
These should all be able to be part of the same pattern.
Patterns that focus on long run lengths might not be
effective for tests that want more like the "average"
run.
Some want seeds that generate patterns to cover all tests.
The programmability allows multiple classes of tests if a
user wants to run separate tests.
We still have a square wave.
Perhaps we should define the pattern for jitter. If another
party feels a different pattern is necessary for eye mask
or something else, they should propose that along with a
pattern for it.
Data Flexibility:
Allow for all 0s or LF.
LF only has 6 1s in it but the density seems to be high enough
to change the content of the scrambler.
Something with all 1s makes it hard to get the long run lengths.
You still have the seed to play with.
Limiting the flexibility of the data input makes the search more
difficult for a seed.
You can always get the long run. The data input selected makes
the difference on how fast the pattern converts to the more
typical data pattern. Getting the initial 58 bits that you
require should be the most interesting part.
Some receivers may always consider the first word in error and
use it for sync. We don't want to put the stressful par of the
test on the first block.
The length of the seed is 58 bits.
Does the receiver need to sync to the patterns? How does it
move between segments? Does it count? Does it use the first
block for sync and expect 4 errors for each iteration?
Always use 2 seeds. Can load both seeds with the same value.
If there are 4 errors for each iteration, the receiver doesn't
even need to know what the expected seeds are. Otherwise,
we need a sync state machine.
The advantage of sync is more addressing on your bit error
rate. With 4 error method, it limits your BER. You lose 1
block per 8448 bits (128 blocks).
There shouldn't be a lot of work to make the sync logic.
The work is developing the protocol for synchronizing.
If you count errors by block, there is 1 error per seed
change. If you count by bit, this is a harder analysis.
We agreed previously to count by block.
For the receiving PCS using the non-sync method, have the
PCS not count the first error after each 128-block window.
For a BERT that is comparing bits and not getting sync to
the blocks, than it can count bit errors (as compared to the
expected pattern via download?).
How do we pick what the patterns look like?
Run length of ~50 bits
This should also do a reasonable job of providing
transition density and frequency change
Do we need to specify a slope for running disparity?
RMS base line wander sigma set at 2.5% normalised to half the
eye opening. If we use the criteria for events occuring once
per day, 2^15, roughly 8 sigma. Use something like this rather
than specifying "run of x bits followed by run of y bits, etc.".
If we're specifying corner frequencies of PLLs, there might
be longer time constants we should use to affect these PLLs.
We may need to do some calculations to find the likelihood of
3% imbalance in so many bits. Without knowing the offset, you
don't know how many bits this has to occur for to make it
affet the receiver. Is this close enough?
This is mhy the pattern is programmable. We can come up with
one that is reasonable and allow other to be developed in the
future. We wanted things to happen once per day but that isn't
particularly easy to calculate. The trouble with these
caluculation is the exponents get too high to use a typical
calculator.
You can view the scrambler as a bandpass filter. It doesn't
pass frequencies too low or too high.
You can have a bad pattern with a short scrambler. With ATM,
there can be killer patterns for short durations. The long
scrambler tends to avoid that.
How long should the disparity difference be run over? It
depends on the time constant of the receiver. Is this 2-3000
bits, based on baseline wander and PLL bandwidth? This
is probably close enough. Even if it is wrong, the difference
in result should be small.
Should we try to get a seed out before next week?
Even if it isn't the right seed, a dry run on the format
might be very worthwhile to get something out in front of
the group. It might get others thinking about it. It might
increase the probability that someone will say it is too
hard or not hard enough.
The seed should put the stress in the middle of the pattern.
Future work:
I'll send out another copy of the presentation.
Piers will review Clause 52 for required changes.
Next week is the meeting so no conference call.
Thanks to all for attending!
Call ended at 2:30 EDT
SJTP_update_010515.ppt