Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Loop Bandwidth for 64B66B




Hello,

It seems to me that the use of 64B66B code may adversely affect the design
of a Clock Multiplier Unit in a Serial PMD, though I have not quantified it
to decide the magnitude of the problem. This is not a flaw in the 64B66B
code, but rather an unfortunate consequence of the way frequency
multiplication works out. I think this problem can also occur if we use
other low-overhead codes.

To simplify, let's take a specific example. Suppose a Serial PMD's transmit
path is designed such that data received at the HARI interface is decoded
to 8B, then again encoded using 64B66B for optical transmission. Width of
SerDes data path is 8. So the output of the 64B66B encoder must find a way
to ship out data in chunks of 8 bits. This requires a clock frequency
conversion from f_in to
f_out = f_in * 66/8 = f_in * 33/4.

A typical Clock Multiplier Unit implementation will have a phase detector,
comparing the phases of f_in/4 and f_out/33, where f_out is the output of a
VCO. In our example, f_in will be 156.25 MHz, and f_out will be 1.289 GHz.
The input to 8:1 SerDes will be this 1.289 GHz clock, and 8-wide data.

It is the integer 33 that is at the heart of this problem. One can argue
that this makes for a "stiff" PLL - the VCO, whose job is to put out f_out,
is being refreshed at a rate of f_out/33 - resulting in an unusually low
loop bandwidth. This may be generally regarded as a Bad Thing because:

1. It increases the probability of VCO drift, making it difficult to meet
the frequency tolerance specification.

2. Alternatively, it forces the use of a large capacitor in the low pass
filter that will reside at the output of the phase detector. Large
capacitors have to be external. That increases noise susceptibility.

3. It increases low-frequency jitter. Phase noise in VCO output at all
frequencies above the loop bandwidth will reach SerDes.

4. It increases lock acquisition time of a PLL.

My question: is this a big problem, or is this a small issue, routinely
handled using careful design practices? If a non-proprietary solution is
known, what is it?

(In theory, an 11:1 SerDes will eliminate this problem! But it's a good
idea to keep the SerDes width to 2^N.)

Thanks,
Vipul

Vipul Bhatt
Finisar Corporation
(408)548-0813
vipul.bhatt@xxxxxxxxxxx