Re: XAUI jitter tolerance
All -
>5 MHz was put into the FC document to represent available test equipment at the
time.
The real requirement is to ensure the sinusoidal test signal goes well above the
corner frequency of the CDR. The sine signal represents margin for external EMI,
which can have any frequency up to the Nyquist frequency, which is 1/2 of the
transition density times the data rate (1.56 GHz at 100% transition density).
I was always concerned the intent was not conveyed very well in the FC-MJS
document. If you read the entire document, you will find the frequency range
inconsistently specified to go to 5 MHz, to greater than 5 MHz, and beyond the
CDR corner frequency. Again, the last is the real intention - Figure 9 is a
better representation of this, where the frequency axis has no intentional upper
limit.
Any other MJS historians recall this differently?
Thanks, Tom Lindsay
Vixel
Boaz Shahar wrote:
> Mike,
> Thank you for the detailed explanation about the FC Jitter Spec. I looked at
> an FC document titled:
> "Fibre Channel - Methodologies for Jitter Specification" Rev 10 from June
> 1999.
> In page 23, section 10.3 it said"
> ".....and add an o.1UI Sinusoidal sweep from 637Khz (Which is Fc/1667) to
> 5Mhz."
>
> My understandig is that:
> 1.The 637Khz is replaced by 3125/1667=~1.8Mhz for the XAUI
> 2.That the added sinusoidal jitter component is 0 for frequencies higher
> than 5Mhz in FC
>
> And I want to ask what do you think should be done about (2) for the XAUI:
> Will it be 0 UI Above 5Mhz, or instead of 5Mhz we should use 5*(3125/1062) =
> ~ 15Mhz?
>
> (That is, the 0.1UI Sinusoidal Jitter component which is added in FC in the
> spectrum interval [Fc/1667, 5Mhz], will be added in the same interval for
> XAUI or in the interval [Fc/1667,5*(Fxaui/Ffc)]
>
> Thanks, And regards,
> Boaz Shahar, MystiCom.
>
> > -----Original Message-----
> > From: Mike Jenkins [mailto:jenkins@xxxxxxxx]
> > Sent: Friday, January 05, 2001 5:08 AM
> > To: Allan Liu
> > Cc: stds-802-3-hssg@xxxxxxxx
> > Subject: Re: XAUI jitter tolerance
> >
> >
> >
> > Allan,
> >
> > Nothing in the presently proposed jitter spec (1.8 MHz) prohibits
> > any manufacturer from setting the receiver bandwidth as high as
> > he wants. It only prohibits bandwidths below that value. We don't
> > need to increase the "break" frequency. The only thing that would
> > do is legalize transmitters with worse low frequency jitter.
> >
> > FWIW, here's the rationale used in Fibre Channel for the Fc/1667
> > "break" frequency spec: It's based on a ref clock's low frequency
> > jitter and "wander". This is effectively limited by the frequency
> > tolerance spec (say 100 ppm). The worst case is that the frequency
> > slam back and forth between these extremes:
> >
> > F = Fref * (1 +/- 0.0001) cycles/sec
> >
> > The resulting phase error (the integral of frequency error) is:
> >
> > (Tm/2) * 0.0001 * Fref cycles of the REFCLK
> >
> > where Tm = 1/Fm, and Fm is the rate at which the REFCLK frequency
> > slams back and forth between the 100 ppm limits.
> >
> > If the REFCLK is 1/N of the bit rate (N is generally 10 or 20),
> > then this peak-peak jitter as a percent of the bit period is
> >
> > (Tm/2) * 0.0001 * Fref * N cycles of the bit-rate clock
> >
> > For example, at a modulation rate that is 1/1667 of the bit rate
> > (1.875 MHz for 3.125 Gbps), the jitter is 0.083 of the 320 pS baud.
> > At higher modulation rates, the jitter is proportionally smaller,
> > and at lower modulation rates, the jitter is proportionally larger.
> >
> > Regards,
> > Mike
> >
> >
> > Allan Liu wrote:
> > >
> > > Hi,
> > >
> > > A jitter specification has been proposed by Ali Ghasi of
> > Broadcom for
> > > XAUI. At the December Jitter Meeting in Austin, Texas,
> > Agilent made a
> > > proposal for an improvement. Those presentations, as well
> > as a summary
> > > of the meeting by Anthony Sanders(facilitator of the XAUI
> > Jitter Ad-Hoc)
> > > are available at:
> > >
> > http://www.ieee802.org/3/ae/public/adhoc/serial_pmd/documents/
> > index.html
> > >
> > > Our proposal is to increase the "break" frequency of the jitter
> > > tolerance mask. Currently, the proposal puts that "break"
> > frequency at
> > > 1.8MHz. We are proposing to push it up higher to 3-5MHz.
> > > There are four reasons why we believe the time is ripe for
> > making this
> > > change:
> > >
> > > 1) The current "break" frequency was derived from Fibre
> > Channel which
> > > derived it from Sonet; it's equal to the fundamental
> > frequency divided
> > > by 1667. I have looked long and hard and I have not found any
> > > documentation as to why this number was picked. If anybody has an
> > > explanation, there is massive group of people waiting to hear the
> > > answer, including myself. In the meanwhile, let me just
> > repeat what I
> > > have heard from different people; this is in line with what
> > Larry Devito
> > > of Analog Devices has posted to the reflector before.
> > Current wisdom
> > > has it that this number had to do with old SAW filter
> > technology that
> > > was used at the time Sonet was created. In addition, Sonet had to
> > > contend with the inherent problems with using regenerators
> > in the system
> > > and thus had to make their jitter specs more stringent. And to be
> > > compatible with older systems, today's Sonet systems are
> > designed to the
> > > same old spec. Fibre Channel comes along and copies this spec from
> > > Sonet. Infiniband comes along and copies it from Fibre
> > Channel. And
> > > now, XAUI comes along and also wants to copy it from Fibre
> > Channel. And
> > > nobody knows why! XAUI is brand new and does not carry any
> > old baggage.
> > > We have a chance to do it right and to write the specification to
> > > reflect current technologies and current implementations.
> > >
> > > 2) Today's Fibre Channel systems use receivers with a much higher
> > > bandwidth. My measurements show that they are in the 3-5MHz range.
> > > During the December meeting, Jeff Cain of Cisco said their
> > 1G Ethernet
> > > systems are using SerDes with bandwidths in the same range. And all
> > > these systems are working perfectly. So why do we continue to limit
> > > ourselves to a legacy specification that everybody exceeds?
> > We should
> > > write the XAUI spec to reflect what people are implementing and what
> > > makes sense. And from my understanding of how receivers
> > work, a higher
> > > bandwidth equals better performance.
> > >
> > > 3) Other technologies do not necessarily have the same
> > ambitious cost
> > > structure as Ethernet historically has. XAUI is suppose to be a low
> > > cost interface to connect the optics to the MAC. At
> > 3.125G, it is not
> > > easy to build a functional system. Increasing the "break" frequency
> > > means that the receiver is able to track more jitter. This
> > will make it
> > > easier for everybody to meet specification and produce a fuctional
> > > system. And of course, this will drive down the cost of
> > each port. But
> > > the crucial point is not cost, but that increasing the
> > break frequency
> > > will NOT impact system performance in any negative way.
> > >
> > > 4) Increasing the "break" frequency will also make it
> > easier and cheaper
> > > for the integration of XAUI into bigger chips, like MACs.
> > Integration
> > > can mean 1 channel of XAUI or 100 channels of XAUI. Obviously the
> > > current generation of XAUI will be discrete, but from the
> > days of HARI,
> > > integration has been the goal. We must not forget this
> > goal as we move
> > > forward with the specification. And again, this goes back
> > to the point
> > > about XAUI being a low cost interface. Increasing the
> > bandwidth means
> > > the ability to use a smaller filtering cap in the PLL which means a
> > > higher level of integration can be achieved.
> > >
> > > I believe the result from the straw poll during the
> > December meeting is
> > > short-sighted. There is nothing scary or dangerous about
> > this change.
> > > It is certainly a logical and much needed change to reflect what our
> > > technology can do and what the market is producing. There
> > is no need to
> > > copy other standards, especially if those standards have no
> > technical
> > > basis for their jitter tolerance numbers. However, there are clear
> > > reasons, as listed above, as to why these numbers need to
> > be changed.
> > > Any claims that XAUI can leverage from this standard and
> > that standard
> > > are unfounded. There are no standards out there that has the same
> > > goals as XAUI or have the same fundamental frequency as XAUI. And
> > > why should XAUI continue to carry the old baggage as the other
> > > standards do? XAUI was suppose to be easy. After all,
> > 3.125G is only
> > > only 625MHz from 2.5G. Wrong! XAUI chips have yet to be abundantly
> > > available. This suggests that they are much harder to
> > implement than
> > > people previously thought. Any thoughts of XAUI being easy
> > because it's
> > > "similar" to other standards are simply preposterous.
> > >
> > > This message is to open up this discussion to a wider
> > audience and to
> > > get people thinking about this issue as we approach the
> > next meeting.
> > > Any and all input on this matter is appreciated.
> > >
> > > Regards,
> > >
> > > -Allan
> >
> > --
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > 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 |_____|
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
begin:vcard
n:Lindsay;Tom
tel;fax:425/806-4050
tel;work:425/806-4074
x-mozilla-html:TRUE
org:Vixel Engineering
adr:;;11911 Northcreek Pkwy So.;Bothell;WA;98011;USA
version:2.1
email;internet:Tom.Lindsay@xxxxxxxxx
title:Standards & Specifications
x-mozilla-cpt:;-5760
fn:Tom Lindsay
end:vcard