Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: 64/66 system benefits and ad-hoc agenda

Dear Kamran,

Kamran Azadet <ka@xxxxxxxxxxxxxxxxxx> writes:
> My understanding was that there is already enough overhead in the
> Ethernet packets ( for ex: in the IPG or preamble which can be
> stripped out and restored before entering the MAC), that one should be
> able to construct a code that does not require any extra overhead. 

Yes you may do this, but such a code will introduce extra coding
latency.  I am biased towards code with low latency so that the code
will have good performance when used for memory-cpu links in
multiprocessor computer systems. 

I acknowledge and understand that latency is currently a non-issue for
traditional ethernet.  However, I think that latency-sensitive
applications are growing in importance, so I am using latency as a
second-order metric to help choose between various code designs. 

The beauty of the 64/66 code is that it takes HARI as a given and does
nothing particularly tricky to transparently support HARI.

> >> 5) rate conversion 64 to 66: puts some burden on the 10GHz PLL
> >> design, and requires rate conversion + FIFO. 
> >This is always the case in a code that expands the space.  8B/10B
> >needs a rate conversion.  SONET also needs similar circuitry. 
> 8b/10b seems to be a given for Hari.  If one were to keep a rate of
> 12.5Gb/s then there is no rate conversion.  Also if the WWDM scheme is
> based on 8b/10b there wouldn't be any rate conversion in the PHY. 

The 64/66 code is not targeted in any way to WWDM, so that seems to be
irrelevant.  The 12.5Gb/s is also not the target of the 64/66 code.  If
12.5Gb/s is doable, then there is no need for 64/66.  64/66 only exists
upon the premise that 12.5Gb/s is not practical for the forseeable

Given this, then I think we are stuck with rate conversion.  We need to
strip off the 8B/10B overhead, and recode it in some way to maintain
delineation of control and data.

> With respect to SONET I thought typical mux designs are based on a
> simple 4:1 (or 16:1) and that's the type of circuit available today. 
> I don't see how one could map 66 bits into a 4:1 mux easily and
> therefore don't understand why the 64b/66b is not affecting the
> design of high-speed mux/demux and CDR.  It seems this is a drawback
> of a 66b proposal.  Could you please elaborate why you believe this is
> a non-issue? 

There are several ways.  One involves a 4-bit barrel shifter which is
permuted on each transfer.  The second (with more latency) composes a
66*2 bit = 132 bit internal frame and then sends it as 33 four-bit

> With respect to synchronization, I think I shouldn't have used the
> term "start-up", that was an unfortunate choice (I did not imply
> handshaking between local and receive transceivers).What I meant was
> synchronization procedure or hunt state . In both approaches SDL or
> 64b66b block code, in catastrophic situations, there is need for a
> finite period of time to aquire synchornization.  Why is this specific
> to the Nortel proposal?  I thought in order to find the beginning of
> the 66b blocks, one would also have to use a sliding window technique
> combined with multiple checks before entering the sync state. 

That's correct.  The only difference is the complexity of the "multiple
checks".  In 64/66 you simply look for the a stable master transition over
several frames.  In the Nortel code, you must read a (potentially garbage)
packet header to get a length field, compute a CRC over that field, and
then check if it matches the CRC at the end of packet.  If you fail, then
you slip over a bit and try again.

The mechanism to decide on alignment is about the same in both cases. 
The onerous bit is just the packet decoding and CRC computation.  The
64/66 operates soley on frame by frame information and does not need to
"understand" any of the packet contents. 

Best regards,
Rick Walker