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
future.
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
transfers.
> 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