re: PHYs with 10.000 and 9.584640
Bill:
I believe you have a very important point. Many of the issues which are
being debated in the rate discussion stem from the perspective of some
particular encoding system. Personally I assume the encoding is not yet
determined and will not be determined until after we have a task force. I
believed the committee needs to debate and decide the encoding before it
can forge the compromises necessary to settle the rate issue.
I infer from the discussion that people associate 8b/10b with 10.000 and
scrambled encode with 9.584640. I think this is very misleading. All the
proposed encode systems can be used at either rate. This also goes for the
issues of dual clocks. The clock frequencies for scrambling vs. 8/10 vs.
16/18 vs. etc. are all different.
Paul
At 12:18 PM 7/23/99 -0700, 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.
>
>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
>
>
Paul A. Bottorff, Director Switching Architecture
Bay Architecture Laboratory
Nortel Networks, Inc.
4401 Great America Parkway
Santa Clara, CA 95052-8185
Tel: 408 495 3365 Fax: 408 495 1299 ESN: 265 3365
email: pbottorf@xxxxxxxxxxxxxxxxxx