[EFM] PMD timing parameters (3 options revisited)
All,
Here is a comparison chart for overhead associated with options A, B,
and C (per
http://grouper.ieee.org/groups/802/3/efm/public/nov02/optics/bhatt_gener
al_1_1102.pdf ).
The difference with what was presented in
http://grouper.ieee.org/groups/802/3/efm/public/nov02/optics/murphy_opti
cs_1_1102.pdf is that here we take into account the effects of P2MP
protocol as well as timing parameters of the three options.
It seems that the difference in utilization becomes a negligible factor
and should not influence the choice of PMD values. Any comments?
Glen
> -----Original Message-----
> From: owner-stds-802-3-efm@majordomo.ieee.org
> [mailto:owner-stds-802-3-efm@majordomo.ieee.org] On Behalf
> Of Thomas.Murphy@xxxxxxxxxxxx
> Sent: Wednesday, November 27, 2002 10:25 AM
> To: stds-802-3-efm@ieee.org; piers_dawe@agilent.com;
> Vipul_Bhatt@xxxxxxxx; wdiab@xxxxxxxxx
> Subject: [EFM] Minutes from PON Optics Telephone
> Conference - 27th November
>
>
> Attendees
> ----------------------------------
>
> Lior Khermosk
> Bob Deri
> Mike Wirtz
> Vincent Bemmel
> Francois Fredricx
> Haim Ben-Amram
> Raanan Ivry
> Morris Reintjes
> Vipul Bhatt
> Meir Bartur
> Trement Miao
> Tom Murphy
> Glen Krammer
>
> Reset required for Rx options
> ----------------------------------
>
> As already stated in a number of reflector e-mails, the
> feeling of the
> majority
> of people on the call was that a Reset signal is not
> required for Rx side
> (for Option A, or others).
> The point was made that if Reset is required in particular
> designs, then the
> Option A
> values cannot be achieved due to timing uncertainties and
> this point should
> be reflected in presenting
> variants. An attempt was made to decouple the Reset
> discussions from the
> 'PMD' discussions and
> allow the P2MP people to answer the question if it is
> possible and how much
> effort is
> required. No decision was reached that Reset is not
> required.
>
> PON Timing
> ----------------------------------
>
> The idea was floated of saying that irrespective of their
> exact values,
> burst-mode TRx timing parameters for all 4 options
> would be upper limit starting points which would be
> negotiated allowing
> shorter implementation values. There was opposition to
> this
> mainly as it could lead to a situation of several PMDs
> being demanded to
> meet the same spec - single non-negotiable
> value - single PMD. It should be noted that negotiation
> features are already
> in place in the protocol, the question here
> is whether to use them or not. The point was also made
> that this feature
> makes more sense for the CDR as here
> larger variations are to be expected in practical
> implementations. This
> issues needs to be raised again
> when more definite timing parameters are on the table.
> I.e. if consensus is
> for looser timing values, it perhaps
> makes more sense to allow negotiation to accommodate
> future faster
> designs...
>
> Moving forward
> ----------------------------------
>
> For now, the group will stay with discussing and refining
> the four options
> as presented by
> Vipul. Aim would of course be to reach a single option
> agreed upon by the
> group
> and present this in January. However, this may not happen
>
> Next Meeting
> ----------------------------------
>
> Next Thursday 5th December. Probably at 08:00 Pacific,
> Dial-in to be
> confirmed
>
> All the best
>
> Tom
>
>
>
PMD_overhead.xls