RE: 64/66 system benifits and ad-hoc agenda
Kamran,
While it may be correctly argued that Hari is ideal for a WWDM
implementation, its pedigree is not WWDM specific. It was well understood at
the time that we kicked-off Hari that it would be impossible to build an
interface that represented the optimal solution for each of the potential
PMD types. Clearly, any "4-by" solution (WWDM, parallel) is fairly simple.
The concept of Muxing serial streams which are well behaved (DC balanced,
limited run lengths, etc) is difficult to overcome no matter what the
encoding scheme. While my analysis is less than exhaustive, I have found no
case where the simple muxing of a "well behaved" serial stream guarantees
the positive characteristics of the coding scheme.
I bring this up NOT to start another Hari religious discussion, but because
at the time Hari was proposed, no 64b/66b coding concept was conceived (or
at least on the table). If it is possible to modify the 64b/66b concept such
that it can transparently mux/demux across an arbitrary number of lanes,
this should certainly be considered for Hari. While it may not be of
significant impact to the chip technology or implementation, it would
provide a solution that would travel longer distances across FR-4, have a
lower (and wider) harmonic content, and be strongly advantaged in the
Mux/Demux department.
Sans this, I would leave Hari alone.
jonathan
-----Original Message-----
From: owner-stds-802-3-hssg-64b66b@xxxxxxxx
[mailto:owner-stds-802-3-hssg-64b66b@xxxxxxxx]On Behalf Of Kamran Azadet
Sent: Wednesday, December 22, 1999 8:18 AM
To: stds-802-3-hssg-64b66b@xxxxxxxx
Cc: ka@xxxxxxxxxxxxxxxxxx
Subject: Re: 64/66 system benifits and ad-hoc agenda
Hi Rick,
I totally agree with you. I understand the motivation behind a
low-overhead
block code for serial links: increase operating distance on fibers, relax
specs on the
optics, low latency.
The Hari interface is a perfect match (probably was designed) for a WWDM
transceiver.
Unless the serial transceivers use simple 4:1 bit-wise muxing of the 4
lanes of Hari (which
would destroy the structure of the 8b/10b code and seems a wasteful method)
the use of
any other code requires many extra operations such as decoding/recoding
8b/10b,
deskewing bytes, encode/decode (with new code), rate conversion + FIFO,
etc.
But if the 8b/10b code is already set in Hari, then we'll have to live with
it I guess!
Thanks,
Kamran
Rick Walker wrote:
> 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