SJTP: Minutes from 08-May meeting
All,
Thanks for your participation. Attached are the minutes from
today's conference call. Also, attached is an updated copy of
the presentation. Please review before Thursday evening as I
intend to make it available to the task force at that time.
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
8-May-2001, 1:00pm EDT
Attendees:
Ben Brown
Bill Reysen
Pat Thaler
Jennifer Evans
Gareth Edwards
Don Alderrou
Piers Dawe
Tim Warland
Tom Lindsay
Proposed Agenda:
Review the presentation I circulated yesterday.
Begin putting in place the TBDs that will allow John Ewen
(and others?) to start looking for seeds to generate the
patterns.
Discussion:
Square wave discussion
Don't need both high and low frequency
11 works for 66-bits
heard requests for 4 or 8
Use the range between 4 & 11
Covers:
Extinction ratio
OMA
Rise/Fall time (?)
Rise/Fall currently says to use a random pattern
With a piece of equipment, it needs a reference clock so
a square wave works best for this.
Why is this?
Make an eye-diagram, use the average rise and fall times
Piers will check all tests to find out what patterns they
currently use.
Separate list of tests between square wave and random pattern.
* This discussion references an email from Piers that came out
just before the meeting.
Objectives are too weak!
These objectives are nice but have nothing to do with
interoperability.
There is disagreement with this.
It only needs to be long enough to reach a particular BER.
These objectives can be more targeted.
1) Guard against bad PLLs
We haven't proven we need a particular pattern or if any random
data will work.
WWe may not know this information until we get some designs out.
That's why we;re trying to pick a "tough" pattern.
2) Shorten measurement times
This is very subjective.
3) Make measurements more consistent
Would they be inconsistent if we didn't take special precautions?
Does it really matter that we choose special patterns?
4) Perform diagnostics
Educational perhaps but not necessary for the standard
5) Fill a hole
We should define this hole!
The hole is the fact that 52 references patterns in 49 and 50
6) Guard against inappropriate frquency response
Caught by existing tests - stressed receiver sensitivity test.
There is also a low bandwidth issue that this test doesn't
cover so we need something special for it.
What would be an appropriate pattern for stressed receiver
sensitivity test? The new random pattern is adequate.
It sounds like we don't need a new pattern, the existing x31 is
fine.
The problem with the x31 is that it requires the PLL to capture
a signal that is different from the "real" signal. This new
pattern has the sync bits that a PLL might be built to require.
Also to use existing logic.
Also to get a pattern that occurs once per day.
Once per day may be overkill, once per hour might be enough.
These are motivations rather than objectives.
Robust test pattern
Sufficiently stressful to test PLL designs
Easy to generate
When I release this presentation to the task force, where should
I put it?
Space for this in serial ad-hoc documents since it is a draft.
Add square wave pattern
transmit only
can vary from 4on/4off to 11on/11off, based on your implementation
Eye mask test:
Might want a shorter pattern.
Do we do this with a variable pattern length or 2 fixed lengths,
one long, one short? The long pattern doesn't work for this test.
What is the intent of this test?
Jitter and everything else is useless because that is what
the other tests do.
This test should be qualitative not quantitative and doesn't
need a particularly special pattern.
This is a lab test thing, not something done in the field.
It should still be a system test, not optics xcvr alone.
In the field is where you run the larger BER test.
In the eye mask test, you're not looking for the very rare
event but rather something that occurs much more often so
a shorter test is more desired.
What's the problem with a longer pattern?
There's a likelihood of sampling a 5 or 6 sigma event that
you don't want in your eye mask test.
We need the whole pattern within 8k bits (2^13). 1k bits is
probably long enough (per pass in a 4 pass system). Using
the same seed twice, this gets it to 2k bits per loop (2^11).
With a pattern that is really this short, the comment is
being withdrawn. The test might want high-probablility data
or low probability data. With programmable seeds, either can
be used.
BERTs can support up to 8 Mbits. We don't need anything nearly
that long. 8kbits is certainly more than adequate. PLLs don't
have the memory necessary to make that long a pattern required.
TBD discussions:
Length:
Around 1000 but a multiple of 66-bit blocks.
Is there a reqstriction on a BERT to be a multiple of 8?
Perhaps we should also use a multiple of 8 (or higher power).
Don's discussion of last week around different width
implementations prompted a multiple of 256. 256x33 = 8448.
Much longer than the 1000.
64x33 = 2112
32x33 = 1056
Can a short pattern provide a wide enough spectral content?
The scrambler inhibits the low freuency. The pattern repetition
rate will be the lowest frequency, though that is a low energy
level. This shouldn't need to be passed through the filter.
Run rates will also provide low frequency.
The 256 comes from minimum length of a pattern - 4 66-bit blocks
or 264. This allows a 4 x multiple of this or 1056.
Gut feel is that this is too short. Cutting off low frequency
stuff.
10 MHz frquency is possible which is probably the low end
of a PLL design.
Leaning towards 10k bits, 1k bits might be too short.
Fibre channel patterns were 2500 bits that were long enough
to flush problems that 1k bits wouldn't have found.
Argument against designer patterns. Full PRBS is better
because the full range of potential problems exist where
if we look at a specific spot, we can miss something.
Long runs are limited by the sync bits, but they always will
be. A full 66-bit run is very rare, once per many years.
50 bits is a once per day kind of run but we probably don't
even need something that long. 2 bit run is more frequent
than the bit error rate (comes from the x31 PRBS).
Are John Ewen's patterns from last week simply a time shifted
snap shot of the same longer pattern?
Probably not because it may not be possible to replicate
filling the scrambler with all 0s and sourcing all 0s.
If this has to be manufactured, is it a reasonable test?
This is a highly rare event to have occur in real life.
It doesn't take many ones (LF has 6 in 64 bits) and this
changes it dramatically. This is mich more realistic.
Let's close the length discussion: move back to 8k bits.
256x33=8448.
This resolves people's low frequency content issues. As
for the eye mask pattetrn length, using a less aggressive
seed solves that problem.
Future work:
I'll send out another copy of the presentation and
wait a couple of days for responses.
Piers will send a list of what pattern applies to what
test.
Next week, we'll talk more about the TBDs in order to
find seeds to get to a particular pattern.
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 2:40 EDT
SJTP_update_010508.ppt