Re: ONLY one ref multiplier?: PMA clock reference
Stuart,
You are absolutely correct, there are multiple issued being mixed into this
thread. Perhaps the best thing to do is to list them and then to separate this
thread according to the list. Here's my attempt at a list:
1) What interface signals should be specified for the XBI?
Note that the XBI, like the XGMII and XAUI/XGXS would be an optional
interface.
2) If a XBI REFCLK is not specified as a required XBI signal should it be
specified at all?
I believe that this was the root issue in this ever expanding thread.
3) 10 Gbps jitter specs. Includes sub issues like: Should jitter specs differ
for the LAN PHY and WAN PHY? Should they differ for 100 m links and 40 km links?
Should they differ for Serial and WDM versions? Note that this is an orthogonal
issue to the XBI since the XBI is a parallel interface for which jitter is not
relevant. Setup and hold times are relevant for the XBI.
I'll intersperse some direct responses to your note below.
Stuart Brorson wrote:
>
> Hi again,
>
> I feel somehow compelled to join this conversation again -- for better or
> worse.
>
> It seems that we are trying to spec the ins and outs of an interface without
> considering the higher level requirement on the optical signal: the jitter
> performance.
>
> People on this e-mail list have claimed that we can relax the SONET jitter
> specs for 10GigE since the links will only be point to point. This may be
> true, but remember that it depends upon the ability of the receiver to lock
> onto the incoming data stream. And remember that an optical signal
> transported over some distance (e.g. 40 km) picks up *significant* jitter
> because of mechanical vibrations in the fiber, laser wavelength fluctuations
> combined with fiber GVD, etc. Therefore, before we adopt relaxed jitter
> specs, we need to know something about the desired fiber specs, Rx jitter
> tolerance, etc.
I cannot agree more. However, it should be noted that jitter specifications have
a cost, sometimes very high cost, associated with them. I question whether a
single set of jitter specifications is compatible with the P802.3ae 5 Criteria,
specifically economic feasibility. If the cost of 40 km 10 GbE link jitter
specifications adds an order of magnitude to the cost of a 100 m LAN links then
I would say that the standard is broke. Clearly, further discussion is required
to resolve this issue.
> If we need good Tx jitter performance, then a counter clocking architecture
> -- like that in the OIF spec (i.e. stable RefClk into SerDes, and Tx clock
> from SerDes to framer or MAC chip) -- is preferable. This is because the
> stable clock directly drives the SerDes, facilitating a low jitter optical
> stream at the source.
I maintain that counter-clocking the parallel data bus, as in the OIF spec, is
unrelated to the jitter performance of the serial output. I don't believe that
counter-clocking is part of the SUPI proposal and that SUPI is being proposed as
an alternative to the OIF/XBI interface, is it not?
Counter-clocking, if properly implemented, simply supplies data source with a
clock which it returns to the multiplexer with data which is frequency locked to
the REFCLK. Jitter on the counter or data clock signals is irrelevant since all
data is latched and then serialized for transmission. Only setup and hold times
are relevant for the parallel data/clock interface (XBI).
Tx jitter performance is a factor of the cleanliness of the REFCLK, if present,
and if not present, to the jitter attenuation circuit which cleans up the data
clock. Whichever clock source is used to transmit data, that clock must be
further multiplied up to the WDM or serial output line rate. The clock
multiplier circuit is a major contributor to Tx jitter performance.
> An added advantage to counter clocking is that we can leverage chips already
> on the market which implement the OIF standard. Re-use instead of
> re-invention is generally a good thing, unless there are important reasons
> that currently available chips are unsatisfactory for us (e.g. they are too
> expensive or have bad performance).
I am fully in favor of leveraging chips already on the market to enable early 10
GbE products. However, chips won't be going into the standard since they are
implementations. Interface specifications are going into the standard. Care must
be take to ensure that those specifications do not encumber the kind of
implementation innovation that has made Ethernet what it is today.
> If after due consideration we decide that good jitter performance is not
> required, then a simple forwarded clock scheme on the Tx side is sufficient.
> On the other hand, this scheme doesn't allow reuse of the SONET chips. So
> why re-invent the wheel unless there are real reasons to do so?
Jitter performance must be specified in the standard. Clocking schemes will
likely not be since they are implementation dependent. It seems to me that
existing SONET chips will likely meet or exceed the eventual P802.3ae jitter
specs. I find it difficult to fathom that the committee will "tighten" SONET
specs for 10 GbE, further raising the cost of these already very expensive
components.
> Anyway, before simply specifying the signals on the SerDes, I think that we
> need to understand the jitter requirements better.
Yup. Agreed. Let's go to it!
Best Regards,
Rich
> Cheers,
>
> Stuart
>
> -----Original Message-----
> From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
> Sent: Tuesday, June 27, 2000 8:28 PM
> To: HSSG
> Subject: Re: ONLY one ref multiplier?: PMA clock reference
>
> Henning,
>
> Nothing. RX_DATA, RX_CLK, TX_DATA and TX_CLK should do it. The rest should
> be left up to the implementation.
>
> Best Regards,
> Rich
>
> --
>
> "Lysdal, Henning" wrote:
> >
> > Stuart, Justin, all
> >
> > I appologize if my answer to the fairly simple question by Justin:
> > "Are there any that uses the 155MHz as a reference for OC192?"
> > has confused some.
> >
> > My point was to show technical feasibility, so I'll give it a second try,
> > and see if we can get the discussion back on track:
> >
> > Given the choice between a 155.52MHz reference clock and a 622.08 MHz
> > reference clock most of the transceiver vendors (SerDes customers), I
> > know, CHOOSE 155.52MHz.
> >
> > It might be easier to get good jitter performance with 622.08MHz
> > (644.53MHz), but it is also more expensive.
> >
> > Maybe we should start discussing which parts of the OIF spec. should be
> > copied for Ethernet rather than going over the details of which
> > frequencies goes where. I guess we can all agree, we need RXDATA,
> > RX_CLK, TX_DATA and TX_CLK. What else do we need to specify?
> >
> > Regards,
> >
> > Henning
> >
> > -----Original Message-----
> > From: Stuart Brorson [mailto:sdb@xxxxxxxxxxxx]
> > Sent: 23. juni 2000 21:56
> > To: stds-802-3-hssg@xxxxxxxx
> > Subject: RE: ONLY one ref multiplier?: PMA clock reference
> >
> > I did not intend to "beat anybody silly". Rather, I wanted to point out
> > that designing 10 Gig circuits with very low jitter is *hard*, and the
> > difficulty is compounded by using lower speed reference clocks. My friend
> > from (unnamed Danish company) unwittingly proved my point by announcing
> > that their 10 Gig SONET mux chip used a 155 MHz reference. Unfortunately
> > for him, that chip is known in the industry for having jitter problems.
> >
> > More importantly, my real point was that the chip vendors (and the
> > standards body by extension) should not restrict the designer to using a
> > lower speed (i.e. 155 MHz) clock. IMHO, designers want to choose either
> > 155 or 622, and that's the choice the 10 Gig SERDES chip designers
> > correctly give them.
> >
> > In any event, I discovered after posting my initial message that the
> > question of one vs. two clocks involved not the question of 155 vs. 622,
> > but rather how to synthesize both 9.95328 GHz and 10.3125 GHz
> > (WAN vs. LAN) with only one reference clock. Read before you post,
> > I always say!
> >
> > Just to put my two cents into this latter discussion: Since LAN line
> > cards and WAN line cards often use different optics -- and are
> > therefore different designs -- I see no reason that one needs to
> > generate 9.95328 GHz and 10.3125 GHz off the same crystal. Different
> > boards can have different BOMs and call out for different oscillators.
> >
> > Stuart Brorson
> > Axiowave Networks
> > 100 Nickerson Road
> > Marlborough, MA 01752
-------------------------------------------------------
Richard Taborek Sr. Phone: 408-845-6102
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Fax: 408-845-6114
2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com