Re: [Fwd: Xaui jitter tolerance]
Richard,
Apologies. I should have said "the existing Fibre Channel spec
methodology". To my knowledge, 1GbE serdes are generally designed
to that same spec. Ours are anyway.
Once again, leaving the jitter corner frequency at bitrate/1667
allows serdes designers who think it should track fast to design
it that way and those who think jitter tolerance is improved by
lower bandwidth to do that. Increasing the spec only restricts
those options while permitting higher jitter transmitters.
Also, I am not proposing using Sonet specs for XAUI.
Regards,
Mike
richard_dugan@xxxxxxxxxxx wrote:
>
> *
> * From the t11_2 reflector, posted by:
> * richard_dugan@xxxxxxxxxxx
> *
> Mike,
>
> I don't think we can "break an RX designed to the existing spec" since the
> proposed 802.3ae spec does not exist yet. That's why I'm bringing it up
> now, so we can make a reasonable and informed choice for the future of
> 10GbE. I believe that pushing the corner further out on the Rx allows for a
> more robust link, and that that is what is done today in practice.
>
> >From a business point of view, I would argue that there may be very good
> reasons not to use SONET specs for XAUI and Ethernet.
>
> - Richard
>
> > -----Original Message-----
> > From: Mike Jenkins [mailto:jenkins@xxxxxxxx]
> > Sent: Friday, December 01, 2000 1:24 PM
> > To: stds-802-3-hssg@xxxxxxxx
> > Cc: t11_2@xxxxxxxxxxx
> > Subject: Re: [Fwd: Xaui jitter tolerance]
> >
> >
> >
> > Richard,
> >
> > As you say, increasing the jitter corner frequency doesn't hurt
> > or help a fast RX. However, it may break an RX designed to the
> > existing spec. The only thing it helps is a TX that can't meet
> > the jitter output specs with the existing "1667" frequency corner.
> >
> > From a technical point of view, it is arguable whether trying to
> > follow all jitter (faster RX) is better than settling on an average
> > sample point (slower RX), as both Tom and I have pointed out.
> > The existing corner spec allows each designer to make that choice.
> >
> > From a business point of view, it seems a disadvantage to force
> > different specs for one market than for others, particularly if
> > the only thing gained is to help some transmitter designs.
> >
> > Regards,
> > Mike
> >
> > richard_dugan@xxxxxxxxxxx wrote:
> > >
> > > Tom,
> > >
> > > I agree that we should try and figure out why the 1667 was
> > originally picked
> > > in SONET, but I don't agree that I'm proposing a radical
> > difference. As FC
> > > or GbE exists today there is no "max" value for this corner
> > in jitter
> > > tolerance, only a "min". So if you track all the way to
> > 100MHz you would
> > > still meet spec. As a practical matter, it's also probably
> > true that many
> > > designs already track to ~10MHz or so in parts today.
> > >
> > > - Richard
> > >
> > > > -----Original Message-----
> > > > From: Tom Lindsay [mailto:Tom.Lindsay@xxxxxxxxx]
> > > > Sent: Thursday, November 30, 2000 3:13 PM
> > > > To: stds-802-3-hssg@xxxxxxxx; T11.2 posting
> > > > Subject: Re: [Fwd: Xaui jitter tolerance]
> > > >
> > > >
> > > >
> > > > (To FC folks - this message is essentially the same message I
> > > > sent to T11.2 earlier today).
> > > > ******
> > > >
> > > > Mike - refer to Annex G of the FC-MJS report for an
> > > > explanation for 1667. It is something I wrote, so it should
> > > > be questioned...
> > > >
> > > > A lot of the history relates to SONET. I personally would be
> > > > very reluctant to take a radical departure until someone
> > > > really understands why SONET did what they did and what the
> > > > tradeoffs were/are.
> > > >
> > > > The 100ppm requirement would be less of an issue with higher
> > > > corner frequency, not more.
> > > >
> > > > Your point about over-tracking (your CJTPAT discussion) is
> > > > valid. If the CDR is too fast and tracks every little bit of
> > > > noise and jitter that comes along, we're asking for trouble.
> > > > If we think about CDRs as high-pass filters, complex jitter
> > > > with fundamentals below the corner frequency gets
> > > > "differentiated", which can effectively double the peak to
> > > > peak jitter the CDR has to dissipate. (Think about sending a
> > > > low frequency square wave through a high-pass RC filter).
> > > > There has been a lot of work done on this, both analytically
> > > > and in the lab.
> > > >
> > > > Tom Lindsay
> > > > Vixel
> > > > 425/806-4074
> > > >
> > > > >
> > > > > Subject: Re: Xaui jitter tolerance
> > > > > Date: Wed, 29 Nov 2000 20:09:02 -0800
> > > > > From: Mike Jenkins <jenkins@xxxxxxxx>
> > > > > Organization: LSI Logic
> > > > > To: stds-802-3-hssg@xxxxxxxx
> > > > > References: <200011292314.RAA00398@xxxxxxxxxxxxxxxxxxxxxxxx>
> > > > >
> > > > > Richard, Ed,
> > > > >
> > > > > I disagree with the proposal to increase the jitter
> > corner frequency
> > > > > higher than baudrate/1667. First, the number 1667 is
> > tied to the
> > > > > assumed +/-100 ppm reference frequency tolerance. I
> > can't say it's
> > > > > an inviolable law of physics, but 1667 does make sense.
> > (I'll try
> > > > > to dig up the explanation, if you want it.)
> > > > >
> > > > > Second, tracking jitter isn't always a good idea. One
> > Fibre Channel
> > > > > jitter test pattern, CJTPAT, is designed to shift edges
> > late, then
> > > > > early, repetitively. If the RX follows, it's jitter
> > tolerance is
> > > > > reduced compared to averaging out this input jitter and
> > keeping the
> > > > > sampling position fixed.
> > > > >
> > > > > If you would like more feedback on your proposal, I would
> > > > suggest also
> > > > > posting it to the Fibre Channel phy layer reflector,
> > > > t11_2@xxxxxxxxxxxx
> > > > >
> > > > > Regards,
> > > > > Mike
> > > > >
> > > > > Ed Grivna wrote:
> > > > > >
> > > > > > Hi Richard,
> > > > > >
> > > > > > I agree with your viewpoint. Many/most RX PLLs for this
> > > > speed have
> > > > > > BW in the 10+ MHz range, which is what you want to allow
> > > > fast pull-in
> > > > > > and tracking of jitter in high noise environments.
> > The low BW is
> > > > > > generally a carry over from SONET environments where the
> > > > > > repeater functions (and the jitter gain in some parts of
> > > > the PLL transfer
> > > > > > function) can cause problems. As far qas I know, these
> > > > implementations
> > > > > > are all re-timed to a local reference so jitter gain is
> > > > not an issue.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Ed Grivna
> > > > > > Cypress Semiconductor
> > > > > >
> > > > > > > Since XAUI jitter will likely be addressed in a
> > > > separate meeting at Austin,
> > > > > > > I would like to raise the issue of modifying the jitter
> > > > tolerance frequency
> > > > > > > "break point" from the standard baudrate/1667 (used in
> > > > MJS) to something
> > > > > > > significantly higher.
> > > > > > >
> > > > > > > For Xaui, the baudrate/1667 would give us a tolerance
> > > > break point at 1.875
> > > > > > > MHz. My feeling is that there is nothing magical about
> > > > the baudrate/1667
> > > > > > > and that it doesn't accurately reflect typical receiver
> > > > operation in today's
> > > > > > > monolithic PLL's. (Perhaps in early telecom days SAW
> > > > filter applications
> > > > > > > required this, but today's receiver designs (at least
> > > > in XAUI) will not be
> > > > > > > using such costly techniques.) Moving the jitter
> > > > tolerance break point out
> > > > > > > to ~5 MHz or so would allow us to track more of the
> > > > jitter components and
> > > > > > > perhaps even make the Tx design easier (smaller
> > > > capacitors, etc.).
> > > > > > >
> > > > > > > Soo, would there be any objections to moving the
> > > > tolerance break point out?
> > > > > > > I'd like to get some feedback on this before the
> > > > Austin meeting if
> > > > > > > possible.
> > > > > > >
> > > > > > > - Richard Dugan
> > > > >
> > > > > --
> > > > >
> > > >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > Mike Jenkins Phone: 408.433.7901 _____
> > > > > LSI Logic Corp, ms/G715 Fax: 408.433.7461
> > > > LSI|LOGIC| (R)
> > > > > 1525 McCarthy Blvd. mailto:Jenkins@xxxxxxxx
> > | |
> > > > > Milpitas, CA 95035 http://www.lsilogic.com
> > |_____|
> > > > >
> > > >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > >
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Mike Jenkins Phone: 408.433.7901 _____
> > LSI Logic Corp, ms/G715 Fax: 408.433.7461
> > LSI|LOGIC| (R)
> > 1525 McCarthy Blvd. mailto:Jenkins@xxxxxxxx | |
> > Milpitas, CA 95035 http://www.lsilogic.com |_____|
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mike Jenkins Phone: 408.433.7901 _____
LSI Logic Corp, ms/G715 Fax: 408.433.7461 LSI|LOGIC| (R)
1525 McCarthy Blvd. mailto:Jenkins@xxxxxxxx | |
Milpitas, CA 95035 http://www.lsilogic.com |_____|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~pc
begin:vcard
n:Jenkins;Mike
tel;fax:408.433.2840
tel;work:408.433.7901
x-mozilla-html:FALSE
org:LSI Logic Corporation
version:2.1
email;internet:jenkins@xxxxxxxx
title:Principal Engineer
adr;quoted-printable:;;1551 McCarthy Blvd=0D=0AMS G-750;Milpitas;CA;95035;USA
x-mozilla-cpt:;16352
fn:Jenkins, Mike
end:vcard