Thread Links |
Date Links |
||||
---|---|---|---|---|---|

Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |

*To*: vipul.bhatt@xxxxxxxxxxx*Subject*: Re: Loop Bandwidth for 64B66B*From*: Kamran Azadet <ka@xxxxxxxxxxxxxxxxxx>*Date*: Wed, 29 Dec 1999 15:17:11 -0500*CC*: 64B66B reflector <stds-802-3-hssg-64B66B@xxxxxxxx>, ka@xxxxxxxxxxxxxxxxxx*References*: <NDBBLPPAGLKNHFOBGMDPOEIOCBAA.vipul.bhatt@xxxxxxxxxxx>*Sender*: owner-stds-802-3-hssg-64b66b@xxxxxxxx

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

**References**:**Loop Bandwidth for 64B66B***From:*Vipul Bhatt

- Prev by Date:
**Re: 64/66 system benefits and ad-hoc agenda** - Next by Date:
**Loop Bandwidth for 64B66B** - Prev by thread:
**Loop Bandwidth for 64B66B** - Next by thread:
**Re: Loop Bandwidth for 64B66B** - Index(es):