JTP: Feature List Priorities
Okay, so I heard back from a few of you. Jonathan provided a
wonderfully detailed list while a few others provided some
thoughts. These are all listed below. I also heard back on
some preferences regarding conference calls. I think I'd like
to schedule an initial call. Depending upon where that goes,
we'll see if we can continue via email for a while or if we
should schedule another call.
How does Tuesday, 3-Apr, at 1:30 PST sound? I think this
fits into all the times slots that were sent to me. I'll
make the arrangements for a conference number on Monday.
I heard back from 6 people. I'll probably get 10 ports. If
there are more interested parties out there, let me know
so I can get more.
The agenda will be to discuss the relative priorities of the
following features. Once we get these prioritized, the next
step will likely be to review the proposals (those discussed
in Hilton Head or new ones that we haven't seen yet). We
should be prepared to discuss the merits of particular
proposals regarding how they address our feature list.
Thanks,
Ben
"Kesling, Dawson W" wrote:
>
> Since the pattern affects the resulting jitter numbers that are measured,
> one important aspect in my mind is that there be measured jitter performance
> data on real chips to go along with the selected pattern. (I'm not sure that
> this is the case for XAUI and am concerned that be might be in for a rude
> awakening. What I mean is that the jitter spec's might not account for the
> chosen pattern yet.)
>
"Lindsay, Tom" wrote:
>
> No significant thoughts on this except to stress the receiver. Level
> of stress, probability of peak stress are important to be discussed.
>
Jonathan Thatcher wrote:
>
> This is what I remember from a variety of meetings plus a couple of my own:
>
> 1. Relatively short in length (can be loaded into BERT memory).
> 2. Has nearly 50% transition density (+/- tolerance TBD).
> 3. Contains long run lengths
> 3a. Longest length (TBD)
> 3b. Rapid trends towards large disparity (TBD).
> 4. Stresses the PLL clock recovery (TBD). Combinations of:
> 4a. Long run lengths
> 4b. Phase transitions
> 4c. Polarity biased transitions (some PLLs only look at rising or falling
> edges)
> 5. Able to create very short patterns for some optical tests (e.g. OMA or
> E/R).
> 6. Able to run in loop back (need independent Tx and Rx pattern generators)
> 7. Able to count "down" to BER rate of TBD. (10e-3?)
> 8. Able to reset counter
> 9. If two counter registers are required (depends on the TBD in # 7 above),
> one must be slave to the other (slave register loaded when the master is
> read, only).
> 10. Able to synchronize in presence of bit errors (BER TBD).
> 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.
> 14. Stressful, but reasonable, for EMI testing (e.g. no short patterns; see
> #1 above).
>
> I would like to note that number 5 above was not shown in the Ewen/Thatcher
> presentations in March due to information overload. This is simply
> accomplished by turning on and holding on the seed reload active. Easy.
>
> I think that I mentioned in my talk that number 10 could potentially be
> accomplished by use of the error rate counters.... If not, that is one way
> to define and potentially select the synchronization BER.
>
> I would like to note here that I feel very strongly about # 11. I would
> definitely write a TR against the draft if we did not do this. I have zero
> (yep, read that 0) confidence that we will select the ideal pattern(s) in
> the next six months. In short, I believe there is a very high probability
> that some (or all) of the TBDs above will change as we get experience in the
> field. We definitely have history supporting this.
>
> Number 14 is not strictly required since this could be done with real data.
> But, as many of us have already learned on the test field, EMI measurement
> is already a difficult to repeat exercise. It is nice to remove as many of
> the random variables as possible. This is, therefore, not required. But, it
> would be nice.
>
> jonathan
--
-----------------------------------------
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
-----------------------------------------