Estimate required CDR/Locking Time for applications

[Klakx]

Hello,
generally I thought in data communication systems like Ethernet the CDR locks during the preamble. So i assumed the locking time has to be shorter than the preamble time (i.e. 7byte '0' and '1' toggles).

Now I looked for some CDRs and found in the datasheet of AN2813 of analog devices a aquisition time (lock-to-data) of 1.2 ms for GbE. Which is really long compared to a GbE Preamble.

If this CDR should work for GbE then this is not whole story of using a CDR.

Can somebody help me with this question? I think it is a really basic one, but i had no luck with the literature.

 

[dick_freebird]

This all depends on the local clock generation.

I've designed a burst-mode CRU that locked in < 12 cycles
(400MBPS) but this had a stable clock reference that was
slow-slaved to the burst mode data. If you have to slew
an analog PLL loop, starting from nothing, that's going to
be real slow, unless you want to sacrifice a lot of phase
noise (you don't, at gigabits per second).

It might be better for system simplicity to just throw null
packets full time, and substitute real data when it shows
up, than make things burst mode. You could then dispense
with the preamble "tax". Only if extreme power saving can
be had, by going dark in a sparse-duty system, or if there
are multiple talkers time-dividing the link without much order,
does burst mode get you much (in my book, which is more
like a pamphlet).

 

[Klakx]

First, thank you for your answer. It seems that it is more difficult than expected.

This all depends on the local clock generation.

I've designed a burst-mode CRU that locked in < 12 cycles
(400MBPS) but this had a stable clock reference that was
slow-slaved to the burst mode data. If you have to slew
an analog PLL loop, starting from nothing, that's going to
be real slow, unless you want to sacrifice a lot of phase
noise (you don't, at gigabits per second). [..]

I am unfamiliar with burst mode. For me bursting is sending frames with minimal delay between them. So I cannot connect burst and 12 cycles locking. Can you explain it to me, please?

At the next point, if i ve two independedly clocked systems and both systems have a reference clock of +- 100ppm. Do you put this system concept to the case "the pll starts from nothing"?

It might be better for system simplicity to just throw null
packets full time, and substitute real data when it shows
up, than make things burst mode. You could then dispense
with the preamble "tax". Only if extreme power saving can
be had, by going dark in a sparse-duty system, or if there
are multiple talkers time-dividing the link without much order,
does burst mode get you much (in my book, which is more
like a pamphlet).

In the first time I used this technique. But in systems like ethernet it is not possible to occupy the whole channel with zero packets. According to this, is there still another requirement when I can use a "slow" locking CDR?

 

[dick_freebird]

If you have a system-wide clock scheme and each local one
is frequency slaved but of unknown phase (a "slow slaved
clock"), the scheme I refer to works by generating a field of
local locked phases and the incoming packet preamble is
used to pick the best one, which you'll go with for the duration
of the packet. It requires that the frequency not drift much
meanwhile, is all. If packets arrive from multiple sources then
phase will constantly be different but frequency, the same.
How to lock frequency without trying to pull phase, requires
that you tweak the clock much slower than the data packet
rate so it just sort of averages.

Burst mode, to me, is packet, dark fiber, packet... preamble
length needs to accommodate "cold start" and baseline creep
issues with receivers or AC-coupled front ends (if duty cycle
distortion is a "feature" then locking too early will misplace
your strobe edge in the eye, with this sort of adaptive phase
selection scheme.

Selecting a "good enough" existing and stable (w.r.t. data)
phase is the only way I know of to get a fast "lock". If you
have a loop filter to swing, forget it. Basically you want the
loop long term pre-locked and grab the phase that works.

 

[Klakx]

I try to communicate from device to device. So I guess, I ve not a frequency slaved system (every device has his own oscillator). But I am not smarter now.
The AN2813 has a loop filter. Does that mean with 1.5ms Lock-to-Data it is no possible to use it in an "Packet-Dark-Packet" concept? Maybe the timing of GbE protocol could help, but I havent found anything and the specification is a mess.