Re: Loop Bandwidth for 64B66B
Hi Vipul,
that is my feeling too. My main concern about the 64b66b proposal is the
need for
rate conversion. That puts burden on the 10Gb/s SERDES and PLL designs. I'm
less
concerned when a proposal requires change to some digital design. But with the
64b/66b it's not a matter of new digital circuit design, it really does require
special high-speed
analog circuit that is not available today (this may not be a big deal I am not
sure).
In any case I think there is simple ways to do packet delineation without
adding overhead
(as with the 2bit prefix of 64b66b). Both Nortel and Lucent have presented zero
overhead
schemes. These transmission schemes are being used today for Packet over SONET
(PPP/HDLC or SDL). Clock and Data recovery can be implemented using simple
4:1, 8:1 or 16:1 mux/demux, and there is no need for rate conversion after the
Hari
interface decoded [8b data + 1b control] (or am I misunderstanding?)
I think the main objection that Rick Walkers had was complexity of the
scrambling
polynomial and implementation of the Nortel proposal, but I believe that's a
detail that
could be changed. The current scrambling proposal by Rick is in my opinion
elegant
and simple. His scrambler proposal could be adopted for 10G Ethernet.
Is there really any "fundamental" reason why a zero overhead scheme (similar to
SONET but
without SONET framing) is not appropriate for 10GEthernet serial LAN and WAN
PHYs?
Best Regards,
Kamran Azadet
---------------------------------------------------------------------------------------------------------------------
Vipul Bhatt wrote:
> 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