64/66 Feel Good Data

["Rogers, Shawn" <s-rogers@xxxxxx>]

Title: 64/66 Feel Good Data

Rick, I would not be so bold in saying 3.125 Gbaud is "easily" supported in CMOS nor would I say the same for the trace desired trace distance on FR4.  A more correct statement, in my opinion, is that 1.25Gbaud is easily supported in CMOS on FR4.  To achieve stable operation at 3.125Gbaud requires a similar effort in improving IC package capability, mixed signal design, and PCB layout that was required to make 1GbE a reality.  Our own data indicates 1GbE is a walk in the park compared to 3.125Gbaud.

On the 64/66 point:  agree with the benefits it provides the laser guys.  For transceivers, the baud rate is lower (a real plus) :) but the PLL is taxed to stay locked for >10x the run length of 8b/10b (a real negative) :(.  Can't say immediately whether that nets a positive or not. 

HOWEVER, the biggest obstacle for 64/66 acceptance is that it does not currently exist.  No chips have this protocol (if I'm wrong, I'd like samples TODAY!).  No one can test this in the lab, run a library of bit patterns to test for killer packets, check for DC wander, all the stuff that 8b/10b has literally millions of man years piled up against it.  In the absence of this "feel good" data, how can a business manager (a.k.a. risk abatement engineer) commit to implementing this in a product? 

My gut tells me, if there is a need to take the baud rate down from 12.5Gbaud AND a requirement that whatever protocol choosen have the same level of "feel good" there is only one choice:  ATM over SONET scrambling.  It has the same benefits for lasers and transceivers as 64/66 and it has years of testing and implementation.  There is the issue of the synchronous clock in an asynchronous enviroment, but that's probably easier to solve (Danger Will Robinson! No data to back this up!) than building the 64/66 feel good data base.

Happy Holidays,
Regards,
Shawn

 

-----Original Message-----
From: Rick Walker [mailto:walker@xxxxxxxxxxxxxxxxx]
Sent: Tuesday, December 21, 1999 7:30 PM
To: stds-802-3-hssg-64b66b@xxxxxxxx
Subject: Re: 64/66 system benifits and ad-hoc agenda

Dear Kamran,

> is the 64b/66b a proposal for line code in serial link, or could be a
> replacement of 8b/10b also in the Hari interface?  It seems like the
> 8b/10b code is well accepted as the right choice for Hari.  Is this
> still flexible or set in stone (because many companies have already
> started designing their high-speed I/O)?

The 64b/66b code is motivated by the relative difficulty of pushing
existing lasers system to run at 12.5 Gbaud vs 10.3 Gbaud.  At the
higher speeds we have difficult technical challenges in many areas such
as skin loss, dielectric loss, laser relaxation-oscillation time
constants, etc.

The 8b/10b code has a 25% overhead rather than the 3.125% of the
64b/66b, but in return has better control over transition density and
disparity.  At speeds below ~5 Gb/s the overhead of the 8b/10b code can
be ignored with little practical consequence.

Although a code like 64b/66b could be substituted for the 4x 2.5Gb/s
HARI links, there is little incentive because the 3.125 Gbaud
transmission of 8b/10b is easily supported both by CMOS and by the FR-4
PCB infrastructure.

Best regards,
--
Rick Walker