RE: [EFM] PON timing parameters - quick locking
Frank,
Thank you. I think we are on the same page.
If loop timing efficiency is critical, I am certainly supportive of modifying the design assumptions and presumptions in order to achieve the objectives. We'd better decide this in January if we want to get to Working Group ballot anytime soon.
jonathan
p.s. The "I don't understand how it can be done. But, if it is possible to trade "rapid lock" against latency or delay, there could be significant benefits." question stands. This question implies a clock recovery scheme. I should have made it explicit. Perhaps the signal could be split, and slowed down by running one path at absolute zero.... :-)
| -----Original Message-----
| From: FEffenberger@xxxxxxxxxxxxxxxxx
| [mailto:FEffenberger@xxxxxxxxxxxxxxxxx]
| Sent: Wednesday, December 18, 2002 6:29 PM
| To: Jonathan Thatcher; FEffenberger@xxxxxxxxxxxxxxxxx;
| stds-802-3-efm@ieee.org
| Subject: RE: [EFM] PON timing parameters - quick locking
|
|
| Dear Jonathan,
|
| Forgive my misinterpretation of your Email, but you did say:
| "I don't understand how it can be done."
|
| I see where you are going now. Well, I think a big change in
| the modus
| operandi is that all burst mode receivers I've seen don't try
| to regenerate
| the clock from the incoming signal. So, it doesn't make
| sense to define or
| measure jitter transfer, rejection, or tolerance. One does
| define a jitter
| generation in the upstream transmitter, but that largely
| folds into the eye
| diagram.
|
| In short, if you go my way, all the dispersion language you
| know is wrong.
| (But that shouldn't surprise you, because burst mode master-slave
| communication is intrinsically different from continuous mode
| peer-to-peer
| communication.)
|
| You are right that this issue should be dealt with, because
| it goes to the
| heart of the requirement for loop timing the ONU. I wonder:
| what is the
| status of that issue? It is important, and should be
| answered before we go
| any further with specifying PON PMA issues such as the ones
| you have in
| mind.
|
| Sincerely,
| Frank Effenberger.
|
|
| -----Original Message-----
| From: Jonathan Thatcher
| To: FEffenberger@QuantumBridge.com; stds-802-3-efm@ieee.org
| Sent: 12/18/02 7:17 PM
| Subject: RE: [EFM] PON timing parameters - quick locking
|
| Frank,
|
| I have never questioned the ability to do rapid lock times. I
| have seen
| optical systems lock to an incoming signal in a single bit time. But,
| these same systems have nearly zero jitter rejection
| capability. I have
| also worked with several versions of DLL and other
| technologies. All of
| these impact the overall design tradeoffs in different ways.
|
| I have asked, and continue to ask a very simple question: what are the
| specifications and how are these verified. I do not believe
| that any of
| our current test and measurement techniques apply to burst mode
| operation. All of the specifications in the draft presume
| these same T&M
| techniques. If you change the test, you change the specification.
|
| To be convinced that we have a plug and play standard (any compliant
| vendor's part interoperates with any other compliant vendor's part), I
| insist that we see the test methodologies, specifications, and
| engineering that ensure the standard's success. In short, the
| burden of
| proof is on us to establish "technical feasiblity." Without these, the
| draft is not technically complete. This -- according to IEEE 802 and
| 802.3 rules -- is one of the key requirements for entering "Working
| Group Ballot."
|
| jonathan
|
| | -----Original Message-----
| | From: FEffenberger@xxxxxxxxxxxxxxxxx
| | [mailto:FEffenberger@xxxxxxxxxxxxxxxxx]
| | Sent: Wednesday, December 18, 2002 1:08 PM
| | To: stds-802-3-efm@ieee.org
| | Subject: RE: [EFM] PON timing parameters - quick locking
| |
| |
| |
| | (Note: I had to copy the source Email here from the
| archive. For some
| | reason, I'm sporadically receiving EMails from the exploder.
| | I've also
| | tried to re-subscribe, but the moderator seemingly doesn't
| allow me to
| | join... hmmmm.) Anyway:
| |
| | Jonathan,
| | Yes, it is indeed possible to do a CDR in a very short time.
| | I'm glad you
| | found the spec sheet you did. I can tell you that we do it
| | in our lab all
| | the time, and in the field with no problem. We even gave a
| | tutorial on the
| | subject in Edinborough.
| |
| | There are a couple of different schemes to do this, but they
| | all share one
| | common aspect: NO conventional PLLs!! (I emphasize this,
| | because some many
| | people equate CDR with PLL.) If you want to break out of the
| | microsecond
| | realm of CDR lock times, you have to get rid of the PLL.
| | This is obvious,
| | since the loop filter of the PLL is a low pass filter (slow).
| | There is an
| | exception to this, which I'll explain in option #3.
| |
| | Scheme #1 basically over samples the signal with multiple
| | clock phases. One
| | of the phases is bound to be closest to the correct phase,
| | and you pick that
| | one to use for the rest of the burst. One can oversample in time
| | (troublesome at our rates), or in space (multiple delayed
| | copies of the
| | clock). This scheme works if the ONU derives its timing from
| | the OLT signal
| | (which all ONUs do, in practice).
| |
| | Scheme #2, which is patented by Lucent, I believe, basically
| | triggers off of
| | the edges of the incoming signal, and then uses a local clock
| | to carry one
| | through runs of identical digits. As long as the local clock
| | is close to
| | the incoming clock (identical, if the ONT is loop timed),
| | this scheme works
| | quite nicely. Heck, it works with NRZ data, so 8b10b is a
| | piece of cake
| | (maximum run length of 5...)
| |
| | Scheme #3 uses a PLL, but the loop filter is dynamic. When
| | the old burst
| | ends, the loop filter time constant is made very long. So,
| | the PLL stays
| | where it is, and doesn't fly off to infinity. When the new
| | burst starts,
| | the loop filter is made fast, so the phase of the PLL quickly
| | snaps to the
| | new value. This is quicker than you think, because the PLL
| | is already at
| | the right frequency. Then, once the preamble is over, the
| | loop filter is
| | made the usual slow value. This allows the PLL to track slow
| | drifts, as
| | unusual as they may be in the PON setting.
| |
| | So, there you have it. Three ways to do fast clock recovery.
| | Method 2 doesn't even need a reset...
| |
| | Sincerely,
| | Frank Effenberger
| |
| | p.s. Thank you for expanding your horizons.
| |
| |
| | To: <stds-802-3-efm@ieee.org>
| | Subject: RE: [EFM] PON timing parameters
| | From: "Jonathan Thatcher" <Jonathan.Thatcher@xxxxxxxxxxxxxxxxxxxx>
| | Date: Fri, 13 Dec 2002 09:46:23 -0800
| | Sender: owner-stds-802-3-efm@majordomo.ieee.org
| | Thread-Index: AcKiIszkeP7tU0LORVeTtuNw/Wfu8wAqcuNg
| | Thread-Topic: [EFM] PON timing parameters
| |
| | Gerry,
| |
| | Nice chart.
| |
| | I just reviewed a spec sheet for a burst mode CDR. This
| company claims
| | extremely low "lock times***." But, the delay through the
| | chip is a couple
| | of orders of magnitude greater than normal 1000BASE-X CDRs.
| |
| | I don't understand how it can be done. But, if it is
| possible to trade
| | "rapid lock" against latency or delay, there could be
| | significant benefits.
| | This presumes that this magnitude of latency is not of
| concern to EFM.
| |
| | Is it possible to do this?
| |
| | jonathan
| |
| | *** I note that there is no specification for jitter or BER.
| | So, the low
| | lock times might have nothing to do with the extreme latency.
| |
| | | -----Original Message-----
| | | From: Gerry Pesavento [mailto:gerry.pesavento@xxxxxxxxxxxx]
| | | Sent: Thursday, December 12, 2002 1:07 PM
| | | To: FEffenberger@xxxxxxxxxxxxxxxxx; Vipul_Bhatt@xxxxxxxx;
| | | stds-802-3-efm@ieee.org
| | | Subject: RE: [EFM] PON timing parameters
| | |
| | |
| | |
| | | Attached is the timing parameter table, that is the result
| | of the PMD
| | | conference call this morning. As you can see, there has been
| | | significant progress, and two Options are currently on the
| | table. The
| | | OLT parameters are identical. The remaining decision
| | concerns the ONT
| | | laser on/off time (make large and settable, or make small and
| | | fixed).
| | |
| | | Fixed parameters in ONTs (option C) are attractive since
| it will not
| | | require the OLT to keep a table with on/off times per
| ONT. Settable
| | | parameters per OLT are almost mandatory (CDR time is
| | | different with and
| | | without FEC, protocol delay may not be constant, etc). As Frank
| | | mentioned, settable parameters means that during
| | | initialization the OLT
| | | will broadcast a value that represents a number of idles that
| | | ONT should
| | | transmit at the beginning of the burst. This seems to be a
| | simple and
| | | robust approach.
| | |
| | | Glen/Gerry
| | |
| |
|