Re: PHYs with 10.000 and 9.584640
Hi Bill,
I'll add a few comments below:
Bill Woodruff wrote:
> To HSSG,
>
> >From a phy chip design house:
>
> I'd like to talk about two specific PHY implementations (even though the topic is a MAC data rate topic..)
>
> (one possible) SONET type implementation is at 9.952Gb/s line rate, with a 2^n width (i.e. x16, x32). The monolithic VCO's I'm familar with track a reference clock, and the VCO tuning range can easily cover a 0.05GHz range to cover both 9.952G and 10.0G. It is reasonable for the VCO to track down to 9.584640G up to 10G if we overlook the minor issue of just the raw data rate.
>
> The big issue would be that the 10.0G line of thinking implies 8b:10b coding. In this case, there are two critical issues. The mux itself will probably be a x10 (or x20) mux, which would not be the same chip. Also, with 8b:10b the line rate would be 12.5Gb/s. Even if the differnent mux widths were not an issue, then the VCO tuning range would be an issue. Spanning from 9.952G to 12.5G in a integrated VCO is a technology hurdle.
I've heard several others say, and I agree with them, that a line rate significantly greater than 10 Gbps is a significant technology hurdle for almost all aspects of the PHY. My assumption is that 10 Gbps is the MAC/PLS rate and that the line rate will likely be limited to 10 GBaud.
For the purpose of this thread, I will only consider PHY proposals which specify a line rate of ~10 GBaud. My assumption is that 8B/10B or any other code with a 25% line rate overhead are the least likely candidates for this PHY. The most likely coding is a Scrambling-based code which is capable of adding 0% overhead, resulting in a maximum line rate of 10 GBaud.
> One other issue for a simple serial implementation is that the x4 implemenation poses a technology problem. The interface to a high speed mux has to be thought of as a word being latched into the mux with a common clock. If the line rate is about 10Gb/s, then a nibble must be tranferred between chips at a 400ps unit interval. This means that the low speed device (assumed to be CMOS), must pass a contiguous nibble with total skew between the 4 bits, including skew to the clock, of less than 200ps (assuming the CMOS guy gets 1/2 the margin budget). This means that the receive side (the high speed mux) has a clock to Q type window of 200ps, leaving zero budget for board, connector, rise/fall time budgets and tester tolerance. Whew! And, if the line rate is 12.5Gbs, a x4 nibble would have a total of 320ps clock period.
>
> The x4 proposal may be fine for the WWDM guys where deskew is assumed, but we don't want to force the simple serial approach to have deskew for two chips right next to each other. Let's keep the x16 622MHz interface (or wider) for the 2^n interface, or a x10 (or wider) interface for the 8b:10b based approaches.
I'm assuming that the x4 interface you're referring to is the Quad Serial inter-PHY interface being proposed by Howard Frazier of Cisco and several others. If we're on the same page, then I envision a requirement to provide a transceiver to chip interface which may span a significant distance, possibly more than a foot. Interfaces wider than the x4 result in higher pin counts at the (multi) MAC/PHY chip and transceiver. Additionally, these wider interfaces may be EMC exposed relative to serial-based interfaces.
I and Transcendata have endorsed Howard Frazier's proposal for use in the proposed Multilevel Amplitude Signaling (MAS) PHY. Our plan is to deskew and decode within the transceiver. The cost of this additional logic is negligible (relative to FEC and DAC/ADC logic), and the timing of the interface fits reasonably well with clocking requirements for 4D PAM5 modulation.
I am not trying to sway the simple serial proposals from deviating from interface simplicity. However, the x4 approach very cleanly solves a generic MAC/PHY to transceiver interface issue in a very cost effective manner for a MAS-based PHY.
Best Regards,
Rich
--
> Regards, Bill
>
> Bill Woodruff ph: 805 496-7181 x14
> GiGA North America Inc. fax: 805 496-7507
> 299 W. Hillcrest Dr., Suite 206 woodruff@xxxxxxxxxxx
> Thousand Oaks, CA 91360 http://www.giga.dk/
>
> NFOEC, Chicago, Booth 250, September 27-29, http://www.nfoec.com/
> ECOC, Nice, Booth 31, September 27-29, http://liszt.enst.fr/ecoc99/accueil.htm
>
> >> Hello Brad and other 10G'ers:
>
> >> This looks to me like throwing the problem to the subset of PHY
> >> implementers,
> >> since the HSSG (read subset of marketing, system and MAC engineers) does
>
> >> not know how to solve the impasse and get the 75 % approval to either
> >> 10.000 or 9.584640 Gbps.
>
> >> Are these PHYs going to be capable of sending/receiving both at
> >> 10.000 and 9.584640 Gbps ? This would appear to contradict the
> >> accepted idea in the HSSG that the future standard should be
> >> either 10 or 9.584640 (exclusive, but not both).
>
> >> Are we going to define separate PHYs, one for 10.000 and another
> >> for 9.584640 Gbps ? Then perhaps it would be better to define two
> >> separate PARs and working groups, since behind these two different
> >> clock rates are hidden many additional differences (it is not just
> >> choosing between short-wave or long-wave laser PHYs).
>
> >> Jaime
>
> >> Jaime E. Kardontchik
> >> Micro Linear
> >> San Jose, CA 95131
> >> email: kardontchik.jaime@xxxxxxxxxxx
>
> >> >
> >> > -----Original Message-----
> >> >From: Booth, Brad [mailto:bbooth@xxxxxxxxxx]
> >> >Sent: Wednesday, July 21, 1999 9:22 PM
> >> >To: HSSG
> >> >Subject: RE: 9.584640
> >> >
> >> >
> >> >
> >> >I really liked the proposal that Kevin Daines put on the overhead. One
> >> of
> >> >the reasons that I liked the proposal is that it matched what I
> >> pictured in
> >> >my mind. :-) But there were other technical reasons why I liked it.
> >> The
> >> >proposal for those that missed it was to leave the MAC/PLS data rate at
> >> 10.0
> >> >Gb/s, but to have the PHYs determine what data rate was required. In
> >> the
> >> >case of a LAN PHY, the data rate would be 10.0 Gb/s... a direct match
> >> to the
> >> >MAC/PLS data rate. In the case of a WAN (or OC-192) PHY, the data rate
>
> >> >would be 9.58464 Gb/s and the PHY would obtain that data rate by either
> >> some
> >> >form of flow control or buffering scheme.
> >> >
> >> >I like this because it allows the LAN architectures to remain cost
> >> effective
> >> >while offering the ability to easily concentrate links (i.e. ten 1 GbE
> >> links
> >> >map nicely into one 10 GbE link). This architecture puts a bit of a
> >> cost
> >> >burden on the WAN PHY, but I think that this still results in a cost
> >> >effective solution for OC-192. The WAN solution may not be as low cost
> >> as
> >> >the LAN solution, but show me a Gb/s WAN solution today that is as cost
>
> >> >effective as a Gb/s LAN solution.
> >> >
> >> >The other part that I like is that the only real difference between the
> >> WAN
> >> >and LAN solutions in Kevin's proposal is the PHY. Everything above the
> >> PHY
> >> >(including interface to PHY) remains relatively unchanged. Yes, it's
> >> all
> >> >going much faster, but that's an implementation issue, not a standards
> >> >issue. At least that's my impression. :-)
> >> >
> >> >Just my 2 cents worth,
> >> >Brad
> >> >
> >> >Brad Booth
> >> >Level One Communications, Austin Design Center
> >> >(512) 407-2135 work
> >> >(512) 589-4438 cell
-------------------------------------------------------------
Richard Taborek Sr. Tel: 650 210 8800 x101 or 408 370 9233
Principal Architect Fax: 650 940 1898 or 408 374 3645
Transcendata, Inc. Email: rtaborek@xxxxxxxxxxxxxxxx
1029 Corporation Way http://www.transcendata.com
Palo Alto, CA 94303-4305 Alt email: rtaborek@xxxxxxxxxxxxx