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
| |
|