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
> -----------------------------------------
>