[bp] OIF CEI project documents
Hi Gadhi,
At this point the Optical Internetworking Forum (OIF) Common Electrical Interface (CEI) project is still in development.
As with all of its specifications, the CEI documents will be made public and freely available when development completes.
Completed OIF specification's may be found at:
http://www.oiforum.com/public/impagreements.html
That being said in the interest of being responsive to the industry the latest CEI specification, as a work in progress, is being
transmitted as authorized liaisons to the following organizations:
RapidIO
Network Processor Forum
IEEE 802.3
Two sessions on the CEI project are being presented at DesignCON 2004 this week in Santa Clara.
http://www.designcon.com/conference/tf6.html
http://www.designcon.com/conference/7_wp1.html
Mike Lerer
Chairman OIF PLL Working Group
Consultant to Xilinx
-----Original Message-----
From: owner-stds-802-3-blade@majordomo.ieee.org [mailto:owner-stds-802-3-blade@majordomo.ieee.org] On Behalf Of Gadi Lahat
Sent: Sunday, February 01, 2004 4:00 AM
To: DAmbrosia, John F; anthony.sanders@infineon.com; IEEE@nc.rr.com; ahealey@agere.com; stds-802-3-blade@ieee.org
Subject: 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