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
|