Re: [Fwd: Xaui jitter tolerance]
Hi
Infiniband is using baudrate/1667 for corner frequency just something to
consider as some of the MAUI part will be multi-speed.
Thanks,
Ali
richard_dugan@xxxxxxxxxxx wrote:
>
> 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 |_____|
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >