RE: SJTP: Minutes from today's call
Tom,
Given the limited information provided, "Right on."
The one change would be that we have a goal to provide a pattern that
stresses the link with certain characteristics that have a probability of
occurrence on the order of once per 24 +/- TBD hours. In this way, the Tx
and Rx can be tested in a relatively short time (10's to 100's of seconds)
and still have a degree of assurance that with "actual data patterns" the
link will achieve objectives/requirements/expectations.
jonathan
> -----Original Message-----
> From: Tom Alexander [mailto:Tom_Alexander@xxxxxxxxxxxxxx]
> Sent: Thursday, April 19, 2001 10:06 AM
> To: 'Jonathan Thatcher'; 'Ben Brown'; serialpmd; Paul Bottorff; David
> Martin; Norival Figueira
> Subject: RE: SJTP: Minutes from today's call
>
>
> Hi, Jonathan,
>
> Thanks for taking the time to educate a "jitter-challenged"
> WIS scribe. After reading through your e-mail a few times, I
> think I begin to understand the basic issue. To summarize
> what I believe is the problem:
>
> "The bit patterns seen at the XSBI interface are very
> different in LAN and WAN modes. In LAN mode, this looks like
> a repeating 66-bit sequence with 2 constant bits and 64 bits
> of random data. In WAN mode, this looks like a repeating
> 1,244,160-bit sequence with 3072 constant bits and 1,241,088
> bits of marginally random data. The result is that the jitter
> spectrum seen at the receiver end will be very different in
> LAN and WAN modes. To avoid being forced to relax the jitter
> tolerances for the optics/SERDES in WAN-mode vs LAN-mode or
> vice-versa, therefore, it is necessary to use jitter test
> patterns that mimic the actual data patterns as closely as possible."
>
> Is this correct, or am I still confused?
>
> If this is indeed the case, then I fully agree that the LAN
> and WAN jitter test checker/generator must be different, as
> it seems silly to have different specifications for the LAN
> and WAN optics (defeats the purpose of defining a WAN-PHY in
> the first place).
>
> Cheers,
>
> - Tom
>
> -----Original Message-----
> From: Jonathan Thatcher
> [mailto:Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx]
> Sent: Wednesday, April 18, 2001 8:40 PM
> To: Tom Alexander; 'Ben Brown'; serialpmd; Paul Bottorff;
> David Martin; Norival Figueira
> Subject: RE: SJTP: Minutes from today's call
>
> Tom,
>
> Good questions all. I will give them a try and hope to
> accurately represent
> the opinion of the group at large (based on jitter and test
> pattern ad hoc
> meetings and other PMD discussions). If I am off base, I am
> confident that I
> will get some help :-)
>
> Please see below.
>
> jonathan
>
> > -----Original Message-----
> > From: Tom Alexander [mailto:Tom_Alexander@xxxxxxxxxxxxxx]
> > Sent: Wednesday, April 18, 2001 5:18 PM
> > To: 'Ben Brown'; serialpmd; Paul Bottorff; David Martin; Norival
> > Figueira
> > Subject: RE: SJTP: Minutes from today's call
> >
> >
> >
> > Ben (and others),
> >
> > My 2 cents on the test pattern issue:
> > - the test pattern, as I understand it, is intended to test
> > the PMA/PMD and does nothing for the PCS/WIS;
>
> This is absolutely true. But, I think you understand that the
> PMA/PMD cannot
> be effectively compliance tested without the PCS/WIS.
>
> > - the PMA/PMD are common between LAN and WAN PHY;
> > - if A1/A2 sequences are indeed more stressful, why is it not
> > being used in the LAN test pattern as well?
>
> This is a cost statement. A number of our membership is unwilling to
> consider forcing the additional expense on the /R type PHYs.
>
> > I don't see
> > anything in the standard that would allow an implementer to
> > relax PMA/PMD parameters when a LAN-only PHY is being created;
>
> You are very observant. The specification is written under
> the assumption
> that the optical specifications will in fact remain the same (sans the
> variation in nominal clock). But, (continued below)...
>
> > - therefore, I don't understand why we should have different
> > test patterns for LAN and WAN cases.
> >
>
> ...the reason for the different test patterns is precisely to
> ensure that we
> can have common specifications for the PMA and PMD. The base
> assumption is
> that we MUST assure interoperability. Add to this the optimal
> cost/requirements assumption from above, and you end up with
> one of three
> scenarios.
> 1. The patterns used to test the LAN and WAN PHYs are the same and the
> jitter specifications are different
> or
> 2. The patterns used to test the LAN and WAN PHYs are
> different and the
> jitter specifications are the same
> or
> 3. Both the patterns and the jitter specifications are different.
>
> Thus far, the PHY vendors have shown strong preference for #2.
>
> > Further:
> > - the WAN-PHY has a bypass mode specified, whereby the output
> > of the 64B/66B PCS can be directly passed to the XSBI;
> > - therefore, if a common test pattern can be created and
> > specified in Clause 49, and allowed to be operative in both
> > LAN-PHY and WAN-PHY (bypass) modes, no further changes to the
> > spec are needed;
>
> Partially true. If we did this, we would need (caution, this
> is my opinion)
> to change the specification(s) of the PMD (at least for the
> /W). Given the
> way we normally design the Ethernet specifications, we would
> end up adding
> considerable "margin" to the /W PMD specifications to ensure
> interoperability (the less we know the greater the margin; we
> don't know
> very much, therefore...). This would be due to the inability
> to "know" the
> relationship between the system tested under one set of conditions and
> operated under a different set of conditions across a variety of
> implementations.
>
> > - it would be preferable if this test pattern included
> > stressful conditions such as A1/A2 sequences, for both LAN
> > and WAN cases;
>
> Unlikely to fly in the committee (it's that 75% thing :-)
>
> > - therefore, I would prefer to see option #3 of your e-mail
> > adopted, possibly with modifications to the pattern as
> > mentioned, as this seems to result in the lowest compliance
> > overhead for implementers while still preserving the notion
> > of an integral jitter test facility in the PHY.
>
> Like all the other choices, this one has its caveats. It is
> not obvious that
> (at least at this point in time) we know how to create the
> specifications
> for a pattern/PMA/PMD combination that does not have the
> A1/A2 and still
> stresses the PHY the way the normal SONET frame will.
>
> >
> > An informative note referencing the ITU jitter test pattern
> > might be of use to implementers. However, I would not be in
> > favor of making this mandatory (thus creating two and
> > possibly three different test patterns within 10G Ethernet);
> > in this case, though, as we're going to specify a jitter test
> > pattern anyway, a reference to the ITU pattern might only
> > serve to confuse people.
>
> Good point.
>
> >
> > Cheers,
> >
> > - Tom Alexander
> >
> > -----Original Message-----
> > From: Ben Brown [mailto:bbrown@xxxxxxxx]
> > Sent: Tuesday, April 17, 2001 2:38 PM
> > To: serialpmd; Tom Alexander; Paul Bottorff; David Martin;
> > Norival Figueira
> > Subject: 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
> > -----------------------------------------
> >
>