Re: 64/66 Feel Good Data
Hi Shawn,
"Shawn Rogers" <s-rogers@xxxxxx> writes:
> 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.
I agree with you on all points. My statement was more about what is
likely to be possible in the very near future, rather than what was
current practice.
Numerous papers have been published showing lab results on 3-5 Gb/s CMOS
transceivers. Our own research leads us to believe that, although
tricky now, 3.125 will be supportable in CMOS process in time for
large-volume deployment of 10GbE. We also have numerous simulations and
test measurements showing that pre-emphasized 4Gb/s data can be carried
reliably over 0.5 meters of 4-mil differential trace on FR-4.
All that being said, I agree that 2.5G is much easier than 3.125G. These
last few gigabits/sec are coming at more and more pain for everyone
involved.
> 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.
The key to this is to use tri-stated loop filters. This allows the PLL
to hold the current frequency during long run-lengths. With the same
PLL technology that we've used for Fibre channel, in conjunction with a
tri-state loop, we have had no difficulty meeting SONET run-lengths
of 80 bits.
The 64/66 code has a guaranteed run-length of 66 due to the insertion
of periodic sync bits, so it is always better than SONET in this regard.
Because the industry has been able to accommodate SONET with fully
monolithic low-cost IC designs, I think that the 64/66 code should be no
problem. This is my opinion after 13 years of PLL design experience.
> 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?
The only way is for the business manager to realize that 12.5 Gb lasers
are even riskier at the present time than a new code. In addition,
other nasty issue start to get super-linearly difficult in the area of
skin and dielectric loss, packaging, etc.
The risk issue can be handled in several ways. One is to compare the code
with the millions of man-years of SONET experience. In the areas of
run-length and DC-balance, the 64/66 code is provable better.
If you want to test various patterns, you will have to wait perhaps a
little while longer until a reference C-code implementation is written.
The output of such a program can then be down-loaded into an HP or
Anritsu BERT and serialized.
The 64/66 code has not been built out of whole cloth. It leverages a huge
amount of existing expertise on dc-wander, scrambler jamming susceptibility,
laser driver designs, hamming distance analysis, etc.
It's not being proposed just for the "heck of it". The only reason for
looking at a new code at this time is that the old techniques have, in
some sense, been lazy. A 25% overhead was no big deal when Moore's law
was in full swing. That amount of BW degradation would be recovered
with just 6 months bit-rate growth. However, now that we have started
to reach mature saturation of serial transmission technology, the 25%
overhead is becoming onerous.
> My gut tells me, if there is a need to take the baud rate down from
> 12.5Gbaud AND a requirement that whatever protocol chosen 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 environment, 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.
This could be true. I would encourage you to work on this in parallel.
If ATM over SONET is superior, I'm all in favor of its adoption. At the
moment though, I think that 64/66 is significantly simpler to implement,
requiring less FIFO depth and offering much lower latency. These attributes
make 64/66 easier to implement by more vendors, and translate into lower
power and die size.
I'm not unalterably wedded to 64/66. I'm simply trying to flesh out
what I currently believe is a good alternative. I'm trusting that the
standardization and balloting process will eventually make the right
choice if we all diligently work out the implications of the various
code choices.
kind regards,
--
Rick Walker