RE: PHYs with 10.000 and 9.584640

["Thirion, Walt" <wthirion@xxxxxxxxxx>]

Title: RE: PHYs with 10.000 and 9.584640

I have tried to make it clear in every presentation and every discussion that the line code and the speed are orthogonal issues. What we are trying to decide is the speed as measured at the MAC/PLS interface.

Walter Thirion
Level One Communications
512-407-2110

> -----Original Message-----
> From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> [mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of Paul
> Bottorff
> Sent: Saturday, July 24, 1999 12:47 AM
> To: Bill Woodruff; Jaime Kardontchik; stds-802-3-hssg@xxxxxxxx
> Subject: 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
>