RE: [802.3ae_Serial] Application of power budget model
It's probably worth pointing out that the basic budget and parametric spec
limits were derived in different ways for the different PMDs. The 850 nm
one has to be designed from transmitter down for laser safety reasons. But
the 1310 serial one was designed from the receiver up, by assuming a fairly
ordinary OC-192 receiver. I forget how the 1550 one was designed but then
all the power levels were shifted so that people were feeling the "pain at
both ends", so we felt we had it about right!
We should revisit Del's Proposed Set
<http://www.ieee802.org/3/ae/public/may00/hanson_1_0500.pdf> Of Three 10
Gigabit Ethernet PMDs & Related Specifications
http://www.ieee802.org/3/ae/public/may00/hanson_1_0500.pdf
<http://www.ieee802.org/3/ae/public/may00/hanson_1_0500.pdf> and check that
through all the changes of definition and comment resolution, we have not
mislaid anything valuable.
Piers
-----Original Message-----
From: Tom Lindsay [mailto:tlindsay@xxxxxxxxxxxxxxxxxxxx]
Sent: 22 July 2001 02:37
To: stds-802-3-hssg-serialpmd@xxxxxxxx
Subject: [802.3ae_Serial] Application of power budget model
PMD'rs -
There is consensus that all of the power budgeting numbers in clause 52 (and
53?) need to be reviewed and updated. Also, one of the topics kicking around
is how the power budgeting values in the standard should be related to the
spreadsheet model. Clearly, the latter must be understood as part of the
process of doing the former. So, following on from Pier's slides in Portland
as a starting point for discussion, this email proposes my understanding of
how the values and the model should be related. The real goal is to come to
agreement on a process and get it documented.
Basis values - these values form the basic budget and parametric spec
limits. These values appear to include worst-case Tx and cable and nominal
Rx parameter values.
1. Determine Tx_max based on Rx overload and/or laser safety requirements.
Typically an average power, but overload may want to consider peak (up to 2x
Tx_max).
2. Tx_min=Tx_max-Tx_range. Tx_range is typically 5-7 dB. If Tx_min is in
average power, then
Tx_OMA_min = Tx_min + 3dB
3. Inherent Rx_sensitivity_OMA = Tx_OMA_min - budget
4. As a committee, iterate through steps 2-3, trading budget vs. all other
values such that achievable values are determined and constraints are met
(margin>=0 & P_isi<=3.6 dB).
Stressed Rx sensitivity values in standard - based on the final basis values
above
1. Rx_stress_OMA = Tx_OMA_min
minus passive_loss
In actual Rx stressed sensitivity testing, Rx_stress_OMA can be increased by
the portions of P_mpn, P_rin, P_mn, P_refl, etc. that are included in the
test setup.
2. Vertical_closure = P_isi.
Note - to calculate P_isi, use a value for Rx BW that is equal to that of
the calibration filter used (7500 MHz, etc.).
3-tradeoff values in standard - for each spectral center y and width z
Tx_OMA_min_yz = Tx_OMA_min
plus (passive_loss_yz - passive_loss)
plus (P_mpn_yz)
plus (P_rin_yz)
plus (P_mn_yz)
plus (P_refl_yz)
plus (P_isi_yz - P_isi)
etc.
Expressed differently,
Tx_OMA_min_yz = Rx_stress_OMA
plus (passive_loss_yz + P_mpn_yz + P_rin_yz + P_mn_yz + P_refl_yz, etc.)
plus (P_isi_yz - P_isi)
The variables without _yz are the basis values determined earlier.
This treatment of the "other" penalties (P_mpn, etc.) is debatable, but they
must be accounted for somewhere in the standard. Otherwise it will have
negative margin per the spreadsheet. An option is to subtract some or all of
them in derivation of the stressed Rx sensitvity value. This general area is
at the root of my desire to get this process documented.
Other questions
1. Should basis budget analysis include worst case Rx values (e.g., min BW),
for example to ensure P_isi<=3.6 dB?
2. Should P_cross be included anywhere in Stressed Rx sensitivity specs, or
is it truly a Rx property?
3. Should there be any margin for unknowns, or is the conservatism in the
spreadsheet adequate? Since many of the penalties are uncorrelated, they are
overstated by linear addition in the model.
4. Per the model, "budget" is from TP2 to TP4, whereas system folks will
think of it as being from TP2 to TP3. Is this a concern?
5. Vertical_closure is calibrated on a scope, placing cursors at the
innermost trace "means" per Figure 52-15 in draft 3.1 (non change-bar).
a. While this is clear using something like K28.5s, this probably won't be
clear with our 64/66B test patterns. This is its own issue, but it raises
another question:
b. Which test pattern should be used during calibration - Typical or Jitter?
Sorry to be only the question-guy and not doing more to provide answers. I
will not be able to join the conference call 7/24, but I should be able to
join 7/31.
Thanks,
Tom Lindsay
Stratos
425/672-8005