RE: [EFM] Minutes from PON Optics Telephone Conference - 27th November
Tom,
Could you elaborate on "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."
jonathan
| -----Original Message-----
| From: Thomas.Murphy@infineon.com [mailto:Thomas.Murphy@infineon.com]
| Sent: Wednesday, November 27, 2002 10:25 AM
| To: stds-802-3-efm@ieee.org; piers_dawe@agilent.com;
| Vipul_Bhatt@ieee.org; wdiab@cisco.com
| 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
|
|
|
|
|