re: PHYs with 10.000 and 9.584640
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.
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.
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