Re: 64/66 system benifits and ad-hoc agenda
Richard, Rick, Bill,
Please find below a list of comments/questions about the 64b/66b code.
Since I could not attend the Kauai meeting, I downloaded your presentation and went
through your slides. Sorry if some of these questions have already been addressed at
the Hawai meeting.
1) why are control caracters coded with 7bit as opposed to 8bit for data words? Why
not 8bit (what is the role of the empty spaces in 66b blocks?).
2) isn't there an issue with DC wander (due to very short scrambling polynomial)? I thought
that was a problem in 100BASE-TX (DC wander problem).
3) it seems to me, just looking at the polynomial, that the proposed scrambling polynomial
may have poor spectral poperties (EMC issues). Have you looked at the transmit spectrum
when assuming a packet filled with zeros? The registers 0,1,2 will go in the following cyclic
states: (111) (110) (100) (001) (010) (101) (011), (111) (110) ... (cycle of 7). This
would mean the output spectrum would represent discrete tones(?) Is that acceptable?
4) errors are replicated three times at the output of the self-synchronous descrambler.
It seems to me that there is an issue with Ethernet CRC with the current choice of
polynomial and proposed implementation.
5) rate conversion 64 to 66: puts some burden on the 10GHz PLL design, and requires
rate conversion + FIFO.
-----------------------------
1) is a clarification question. I have a suggestion for 2) 3) and 4): to use a descrambling scheme
similar to 100BASE-TX (not self-synchronized) but with a longer polynomial (perhaps one
of the polynomials used in 1000BASE-T). And I guess if Hari sticks to 8b/10b there is
nothing to do about 5)...
Thanks,
Kamran
-------------------------------------------------------------------------------------------------------
Bill Woodruff wrote:
> Kamran,
>
> Part of the background and basis for Hari was that the 3.125Gb/s rate is about the maximum rate that you can run in a CMOS / PCB environment. Also, there are a large number of CMOS design houses which started with fiberchannel / GE hard macros at the 1Gb/s rate,which have been scalled to 2 to 2.5Gb/s, which are being scalled to 3.125Gb/s. The 8b10b code is comfortable and familiar to both the chip guys and the systems users. The benefits of the 8b10b code are only available though at a 25% overhead.
>
> The observation at the serial line rate for 10Gb/s is that the 25% cost of the 8b10b code pushes the optics and the electronics past 'reasonable' costs in the implementation. If we were able to get the required functionality at a 3.125% overhead instead of a 25% overhead, optics could go farther, and electronics could be made cheaper and lower power.
>
> Since no line code yet exists for 10GE serial, there is no incumbant yet either.
>
> Could the 64b66b code be used though in Hari? In the abstract, why not? Then the Hari channels would run at <2.6Gb/s. But Hari has a great deal of momentum, and is serving as a model for Fibrechannel and Infiniband.
>
> If we focus 64b66b on the 10GE serial topic, we can work toward convergance. If we expand the scope, we can be assured of entertaining email dialog and meetings. But Hari may be too far along to re-visit the coding scheme.
>
> What our challenge is, is to ellicit dialog on this reflector to wring out the 64b66b code to insure that it is robust within the proposed 10.3125Gb/s optical and copper environments.
>
> Regards, Bill
>
> >> Richard,
>
> >> 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)?
>
> >> Regards,
>
> >> Kamran Azadet
> >> Lucent
>
> >> --------------------------------------------------------------------------
> >> -------------------
>
> >> Henning Lysdal wrote:
>
> >> > Richard
> >> >
> >> > Thank you for getting this interesting ad-hoc started.
> >> >
> >> > In my opinion 64/66 is by far the most promissing of all the
> >> > proposed line coding schemes discussed in the HSSG.
> >> >
> >> > Perhaps the most important feature is the ability to use existing
> >> > OC-192 high-speed parts. This will save us all a lot of time in the
> >> > prototype phase. Also it will allow the LAN and the WAN PHY to
> >> > use the same hardward. ie. you can build the same module for
> >> > both. All you need is a selectable coding scheme in the CMOS
> >> > part (needed anyway for the HARI SerDes, assuming HARI goes
> >> > into the standard), and a selectable reference clock for the 10.3125
> >> > Gb/s SerDes.
> >> >
> >> > As I recall, the presentation you gave with Rick Walker, the work is
> >> > almost done, so I don't imagine there will be much debate on the
> >> > ad-hoc reflector. How do you propose we proceed with getting a
> >> > proposal together to bring to the HSSG as soon as the standards
> >> > process is officially started?
> >> >
> >> > Henning Lysdal
> >> > GiGA A/S
> >> >
> >> > -------------------------------------------------
> >> > PLEASE NOTE: NEW PHONE AND FAX NUMBER FROM
> >> > FRIDAY OCTOBER 22nd.
> >> > -------------------------------------------------
> >> > llllllll ii llllllll llllll
> >> > ll ll ll ll
> >> > ll llll ll ll llll llllllllll
> >> > ll ll ll ll ll ll ll
> >> > llllllll ll llllllll ll ll
> >> >
> >> > GIGA A/S
> >> > Mileparken 22, DK-2740 Skovlunde, Denmark
> >> > Tel: +45 7010 1062, Fax: +45 7010 1063
> >> > Direct: +45 44546 154
> >> > e-mail: hl@xxxxxxx, http://www.giga.dk