SJTP: Minutes from today's call
Hello,
Attached are the minutes from today's Serial Jitter Test Pattern
phone call. Thanks to all attendees and a reminder that next
week's phone call is on for the same time and you should be
able to use the same number (listed at the bottom of the
minutes).
Tom, David, Paul, Norival, others with WIS/SONET experience:
The focus of today's discussion was around a test pattern for
the WAN PHY. As (hopefully) you can see in the minutes, we
talked about 4 specific options:
1) No modifications to the WIS, use the LAN pattern as the
WIS payload
2) Use the A1/A2 pattern for framing with no other overhead
bytes and do not restrict the frame duration to 125 usec
3) Use the LAN pattern directly, in a similar fashion to what
is currently defined in D3.0 (i.e., no A1/A2 framing)
4) Do nothing and inform WIS implementors about the pattern
specified in ITU-T G.957 (as described in the minutes and
the attached email from Piers Dawe - CID_pattern).
The advantages of #1 are obvious as the standard doesn't need
to change. However, the problem is with the synchronization
process. If there is a feature in the pattern that causes the
PLL to drop sync consistently on every frame, the sync process
will never get around to sending payload to the PCS for
analysis. But then again, if the PLL can't maintain sync, do
we care?
The other disadvantage is that the pattern is very long for
BERT memory. You can either send the same pattern in every
frame, which probably fits into a BERT, but this does not
contain an integral multiple of 66-bit blocks so a receiving
PCS would lose sync on every SONET frame. You could also send
a pattern which repeats with an integral number of 66-bit
blocks but this requires almost 200,000 66-bit blocks over
exactly 11 SONET frames. This works well in a loopback or
PHY to PHY test but does not fit well in BERT memory.
#2 requires changes to the WIS and may affect implementations
regarding how they pass "payload" between the PCS and the WIS.
This would fix the problem of allowing the pattern to both
fit inside a BERT and be passed to the PCS without loss of sync.
#3 eliminates the A1/A2 pattern which itself is a rather
stressful pattern that should probably not be eliminated from
a WAN PHY test pattern.
#4 has been around for a long time without (public) modification.
This either means it works adequately or has been replaced with
proprietary solutions. Choosing this option has the advantage
(for this ad hoc) that our work becomes focused on the serial
LAN only. However, is this pattern sufficient to guarantee
interoperability? Should we make it mandatory when SONET has
made it optional?
We're very interested in the opinions of people with experience
in this area regarding what other ramifications exist that we
haven't even considered. Your input, or that of anyone else for
that matter, would be greatly appreciated. I'm sure we'll be
discussing this in the next phone call but an email dialog would
be a great way to get some progress out of the way.
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
-----------------------------------------
Second conference call of the Serial Jitter Test Pattern ad-hoc
17-April-2001, 1:00pm EDT
Attendees:
Ben Brown
Piers Dawe
Don Alderrou
Gareth Edwards
Anthony Sanders
John Ewen
Peter Ohlen
Tom Lindsay
Jonathan Thatcher
Pat Thaler
Bill Reysen
Proposed Agenda:
Review the feature list that I updated 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:
JT's #11) Pattern flexibility - move to last on list
JT's #12) Technique for testing the WAN PHY
Do we need A1/A2
There are SONET test patterns: do we need to support them?
Probably not as our patterns should provide the same
characteristics.
We'll be defining a test pattern that will likely be better
than the currently optional SONET patterns.
Do we need to do anything special in the SONET overhead
fields when we're passing this data?
Does a WIS need to send data to the PCS other than payload?
Just have the WIS turn off its scrambler.
Without A1/A2, the WIS will never send payload to the PCS.
Perhaps a PLL design depends upon the existence of the A1/A2
pattern.
A1/A2 is stressful on DC-balance.
SONET folks want this repeated as often as it occurs in
reality. Almost everything else is scrambled so the question
comes down to whether we limit the pattern to payload
space or everywhere else.
How does the BERT decide to capture the pattern?
Do they make a "SONET" BERT that knows how to ignore TOH?
SONET pattern is A1/A2 followed by runs/PRBS.
Options:
1 - use full SONET frame - too long(?), not necessarily
BERTs exist to capture an entire frame
pre-programmed filters exist with A1/A2 twice in a frame
similar to existing SONET patterns
If length of pattern matches SONET frame and scrambling
is turned off, then we've got a repeatable pattern
It would be good to get some WIS designers involved in this
discussion.
2 - Create a test pattern that simply prepends the A1/A2
but does not include any overhead and perhaps the A1/A2
occur more frequently.
3 - use the LAN pattern without A1/A2
This is essentially what we're doing in D3.0
Using a method other than #1 means changes to the WIS.
Different implementations may have problems making changes
to the WIS to support.
Due to the 66-bit blocks, the actual repeat rate requires
11 SONET frames. We're still talking about multiple small
patterns in a single SONET frame so does this really matter?
Are we testing for a BERT or point-to-point?
The pattern may not be contiguous across SONET frames from
a 1-frame BERT pattern.
Add logic in the PCS: Start a 66-bit frame coincident
with the beginning of a SONET frame.
Add logic in the PCS: From this trigger point on (the end
of the SONET frame), stop counting errors until you've lost
sync and regained it.
Another choice would be to use option #2: Send A1/A2 followed
by 8(?) repeats of the LAN pattern.
If pattern forces PLL out of sync, a normal function
WIS would never be in sync and never sending payload to
the PCS. The WIS needs to operate in a special test mode.
The ratio of payload to overhead is 29:1(?). If we make
our pattern length 29 times the length of the A1/A2, the
overall data rates would match normal operation. Does the
SONET frame send all 192 A1s and 192 A2s or a smaller
number?
From Jan PMD minutes, this comes from G.958 (1994), now
in G.957 (2000 or 2001) - Piers to send out a URL to this
email
Go through pattern: ABDCBD...
A - 9 bytes of 1
B - PRBS 7 2000 to 10000 bits or more
D - 192 A1, 192 A2, 192 10101010
C - 9 bytes of 0
A1 = 0xf6
A2 = 0x28
This seems like quite a lot of disparity. We should probably
not remove this from a pattern.
If we need A1/A2, this removes option #3.
If the WIS needs to be in a diagnostic mode, we should not
force ourselves into option #1.
This leaves option #2.
4 - There always exists the option of ignoring the WAN pattern
and moving this discussion to serial LAN only. Let the WAN
do it a different way, i.e., the method described above by
Piers.
Does this ensure interoperability??? SONET has issues with
this now, does this have anything to do with it?
This was developed quite a long time ago and nothing else
has come out so this is either good enough or everyone is
doing something proprietary.
How much margin is being added above this pattern value?
This pattern could be adequate given additional margin built
in above this.
Opinions from the silent majority:
Perhaps we can still do a lot better than what is above.
Let's work on putting our LAN pattern into a full SONET
frame.
Worried about the amount of logic required to be added to
support this additional WAN pattern. There's no point in
specing an unimplementable test - if a BERT doesn't exist
to support the full, multiple SONET frames.
The WAN test pattern generator should live in the WIS.
The WAN test pattern generator should live in the best
place, not necessarily any specific place without
understanding more about it.
We have raised most of the issues around this topic, we
simply need more feedback from folks with WIS experience
to provide the "yea"s and "nay"s we need to come to a
conclusion.
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 set for next week at the same time
and number:
CONFERENCE INFORMATION:
----------------------
* Conference Status: *** NEW ***
* 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:34 EDT
Subject: ITU-T G.957 CID pattern
Date: Tue, 17 Apr 2001 20:23:14 +0200
From: "DAWE,PIERS (A-England,ex1)" <piers_dawe@xxxxxxxxxxx>
To: "'802.3ae Serial'" <stds-802-3-hssg-serialpmd@xxxxxxxx>
This is a repeat of information in my email "Notes from serial PMD call of
16 Jan. 01" sent Thu 18 Jan 2001 20:15 GMT, which the email archiver didn't
capture.
WAN jitter test patterns
------------------------
I reported some more detail I had found on the ITU-T G.957 CID pattern.
Here is an expanded version:
The pattern is defined in informative appendices to G.958 (11/94) and the
currently prepublished G.957. They seem to agree.
[CID]=[A][B][D][C][B][D][A]..
A = all ones 9 bytes long
B = PRBS 7 with mark density of 1/2
C = all zeros 9 bytes long
D = a data block consisting of the first row of section overhead bytes for
the STM-N system under test. In other words A1..n, A2..n, C1..n/3,
10101010..2n/3 where n = 48 or 192. Our "C1..n" are defined in the WIS
clause as J0, Z0..n-1 where 50.3.2.3 says Z0 = 11001100. A1, A2 are not
spelt out but referred to in clause 50; G.707 has A1 = 11110110, A2 =
00101000.
The recommended length for B in G.958 is ideally 10,000 bits with a minimum
recommendation of 2,000 bits, however this is not clearly defined and the
duration should be longer than the longest time constant in the clock
recovery system.
The PRBS 7 is defined in (formerly) G.709, (now) G.707. G.707 (3/96) has
1+X^6+X^7. This is also in the WIS clause 50.3.3 and figure 50-3.
G.958 recommends that the scrambler free runs so that all possible sequences
follow the block of ones and zeros, but recognises that this may be
impractical. Or suggests use fixed worst case phase of PRBS, "for further
study".
The test is seen as a design or subassembly thing rather than a general
acceptance test.
By the way, CID patterns (several options) are implemented in product E4544A
which goes with Agilent BERTs.
Piers
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.