AW: [bp] BER Objective for BPE
Gadi,
we are giving a paper at the DesignCon on Wednesday concerning the StatEye,
so as soon as that is done I guess we can distribute the paper?
Cheers,
Anthony
>-----Ursprüngliche Nachricht-----
>Von: Gadi Lahat [mailto:Gadi@TERA-CHIP.COM]
>Gesendet: Sonntag, 1. Februar 2004 10:00
>An: DAmbrosia, John F; Sanders Anthony (COM ON CE);
>IEEE@nc.rr.com; ahealey@agere.com; stds-802-3-blade@ieee.org
>Betreff: RE: [bp] BER Objective for BPE
>
>
>John
>Till then can you send a link pointing to a good introduction
>? Thanks Gadi
>
>-----Original Message-----
>From: DAmbrosia, John F [mailto:john.dambrosia@tycoelectronics.com]
>Sent: Friday, 30 January, 2004 07:33
>To: anthony.sanders@infineon.com; IEEE@nc.rr.com;
>ahealey@agere.com; stds-802-3-blade@ieee.org
>Subject: RE: [bp] BER Objective for BPE
>
>
>Anthony,
>While many of us are aware of the StatEye methodology from OIF
>efforts, it is fair to say that there are a number of people
>who aren't. With that said, perhaps we can get time at the
>next plenary to do our DesignCon paper to introduce it to more people?
>
>John
>
>-----Original Message-----
>From: owner-stds-802-3-blade@majordomo.ieee.org
>[mailto:owner-stds-802-3-blade@majordomo.ieee.org] On Behalf
>Of anthony.sanders@infineon.com
>Sent: Thursday, January 29, 2004 6:19 PM
>To: IEEE@nc.rr.com; ahealey@agere.com; stds-802-3-blade@ieee.org
>Subject: AW: [bp] BER Objective for BPE
>
>
>Adam, Jeff,
>
>a good thread to start.
>
>I think option.2 seems to be the best way to go i.e.
>calculating the system requirements for a 1e-15 ber, and
>through over-stressed jitter tolerance measurements at 1e-12,
>and bathtub extrapolation gaurentee 1e-15.
>
>For the calibration of the over-stressed ejitter tolerance I
>believe that the StatEye Channel measurement methodology can
>accurately predict the overstressing requirements. And for
>output transmitters the extrapolation of the output jitter is
>also accurate.
>
>Where I believe problems may occur is in the final system
>itself. This is agreeing with your issue of noise floors. I
>believe the link in presence of the complete system e.g. power
>supply glitches, could be limited in terms of BER. Not sure
>how to deal with this yet.
>
>Cheers,
>
>Anthony
>
>
>
>-----Ursprüngliche Nachricht-----
>Von: owner-stds-802-3-blade@majordomo.ieee.org
>[mailto:owner-stds-802-3-blade@majordomo.ieee.org] Im Auftrag
>von Jeff Warren
>Gesendet: Donnerstag, 29. Januar 2004 01:15
>An: Healey, Adam B (Adam); stds-802-3-blade@ieee.org
>Betreff: Re: [bp] BER Objective for BPE
>
>
>Adam,
>
>Correct I did intend for this to be a general discussion
>topic, especially the 'experts' from OIF and UXPi because both
>of these 10G technical specifications require a 10EE-15 BER.
>The 1st approach you've described which includes all elements
>of the BPE standard (transmitter, channel,
>receiver) with a systems compliance test at 10EE-12 combined
>with additional margin to guarantee 10EE-15 seems like a
>reasonable way to go.
>
>Hopefully subsequent BPE reflector traffic will include
>input(s) from the OIF and UXPi experts that established their
>respective 10EE-15 BER
>requirements for 10G backplane applications.
>
> - Jeff
>----- Original Message -----
>From: Healey, Adam B (Adam)
>To: Jeff Warren ; stds-802-3-blade@ieee.org
>Sent: Wednesday, January 28, 2004 6:27 PM
>Subject: RE: [bp] BER Objective for BPE
>
>
>Jeff,
>
>Although you addressed this directly to me, I assume that you
>put this topic to the reflector for general discussion.
>
>As you know, this proposal needs to be brought forward to the
>study group and agreed to by at least a 75% majority before it
>become an objective. I encourage you to make such a motion at
>our next meeting if you feel that this is a necessary change.
>
>Since you directed the message to me, I'll also make some
>remarks as a citizen of 802.3 and not SG chair:
>
>My personal opinion is that it would help if you elaborated on
>what this objective would mean in practice (especially for
>those who do not participate in the OIF).
>
>I am personally aware of system requirements for 1E-15 and
>below, but as you imply in the phrasing of the proposed
>objective, it is prohibitive to measure such low error rates.
>The specific language you use implies that we will define a
>system that is guaranteed to work at a BER of 1E-15 but we
>will only verify its performance by measuring the BER to
>1E-12. Giving this topic only limited thought, I see a couple
>of ways to approach this:
>
>1. Define the system (transmitter, channel, receiver) such
>that simulated performance is 1E-15, but in compliance test
>performance is only verified to 1E-12. Presumably, parametric
>values specified in the standard include margin to account for
>the difference in what was simulated at 1E-15 and what can
>actually be measured 1E-12. For a quick example, consider
>random jitter. If the link is defined such the peak-peak
>random jitter at 1E-15 is 0.15UI, then the specification would
>presumably incorporate a specification for peak-peak random
>jitter at 1E-12 of 0.133UI.
>
>2. Define a system for performance to 1E-15, and as part of
>compliance test rely on extrapolation of measured data (for
>example, bathtub curves along the vertical or horizontal axis)
>to derive values for 1E-15 that can be compared with the
>specified values.
>
>One interesting observation regarding (1) is that, if we were
>to have a closed eye system (i.e. the solution relies heavily
>on receiver-based equalization, in that the eye at the
>receiver input is closed), I would expect receiver compliance
>to be based on "operation at a given BER when driven by
>compliant driver through a compliant channel." This is the
>model that has been employed in 100/1000M twisted pair links
>and in 10GBASE-CX4. Using the model defined in (1), we would
>drive a compliant channel with a compliant driver and ensure
>that receiver BER performance was better than 1E-12. I would
>argue that this says nothing about the receiver's ability to
>operate at 1E-15. Some additional impairment (worse than
>worst-case transmitter or channel) needs to be included to
>ensure that the appropriate margin is in the receiver design.
>
>With regards to (2), we would run the risk of having a hole in
>the specification (solutions that are both perceived to be
>compliant but are not
>interoperable) since error floors below 1E-12 would be
>undetected and extrapolation would provide misleading results.
>
>In summary, I do not debate that some applications would like
>to see BER exceed 1E-12 (and in some cases, exceed 1E-15).
>With regards to your proposed objective, I think it would be
>useful to get a better understanding of how a Backplane
>Ethernet standard could be judged to have met such an objective or not.
>
>I think members of the OIF community who also participate in
>the SG could share some insight here. I welcome them to do so.
>
>
>Thank you,
>-Adam
>
>-----Original Message-----
>From: Jeff Warren [mailto:IEEE@nc.rr.com]
>Sent: Wednesday, January 28, 2004 11:43 AM
>To: stds-802-3-blade@ieee.org
>Subject: [bp] BER Objective for BPE
>
>
>Adam,
>
>During the recent IEEE Backplane Ethernet (BPE) study group
>(SG) interim meeting in Vancouver, BC. Canada a BER objective
>of 10EE-12 was voted into the initial set of BPE objectives by
>a vote of 32-yes / 3-no / 1-abstain.
>
>I was one of the three negative votes. My reason was simple;
>because these future 10G backplane links in a modular chassis
>are critical network links and the environment (inside the
>box) is much more noisy than external links.
>
>
>I felt the same approach as the OIF CEI implementers agreement
>makes sense; they require a BER of 10EE-15 per lane with the
>test requirement of 10EE-12.
>
>
>I suspect that system vendors will have the same concern with
>this 10EE-12 BER objective for backplane applications and
>voice their concerns when this objective reaches the 802.3 WG
>so it might be better to fix this objective now rather than later.
>
>I would propose a new BER objective, here's some suggested text:
>
>"Support a BER of 10EE-15 or better with the test requirement
>set at 10EE-12".
>
>Cheers,
>
> - Jeff Warren
>
>
>