re[2]: Loop Bandwidth for 64B66B
All,
Anyone that wants to buy a 10.3125Gb/s 16:1, 1:16 mux, implemented in production silicon bipolar process, can easily do so by calling leading semiconductor manufacturers who may have such a part. It may be in stock, with no availability issues.
(this is not a sales pitch. This is a statement of technical feasibility).
Meanwhile there are other interesting issues in Vipul and Kamran's emails. The market has many IC companies doing x16 mux and demux for 9.952 and / or 10.66Gb/s. The common target is the "OIF" interface. Most of those will also be able to do 10.3125. In fact one of the beauties of this code is that it permits this reuse of technology.
All these existing parts have PLLs suitable for Sonet, which has a longer consecutive bit issue than 64b66b.
No PLL design in the 10G to 12.5G arena is easy. Currently available parts do not represent the asymptote of the design art. In a few years (decades?), these mux/demux parts will be in commodity CMOS, consume <1W, and be practically free. Until then, GiGA and our competitors will compete to provide the lowest power and cost, with the best features.
So, are there any hard issues to implement a 10.3125G Mux/PLL or CDR/Demux? No harder than for a 9.952G part. The other details are at the implementation level.
As for the LBW issue on the mux, the objective on the Tx mux will be to have a LBW as low as possible to reject the nose on the forward clock. The objective is also for a LBW as high as possible to reject the internal phase noise from the on chip VCO. You can't do both at the same time with one PLL.
Are there implementation techniques to solve all these issue? I believe so. My company has its ideas, and I'm sure my competition is not asleep either.
What are the LBW issues required for reliable optical transmission of a 64b66b code? Let's focus on these issues and then task the chip guys to optimize the implementation.
Now, can a chip vendor stand up and give us a comment on availability or issues of a Hari to "OIF" converter?
May we all share a Prosperous New Year!
Bill
>> 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