Re: XAUI jitter tolerance
Hi Allan
Allan Liu wrote:
>
> Hi Mike,
>
> I agree with the general premise of your first point. The jitter
> tolerance mask is a minimum spec, not a maximum spec. So yes, a
> manufacturer can indeed set the receiver bandwidth as high as desired
> without violating the spec. Many people have indicated during the
> Austin meeting as well as on the reflector that today's receivers are
> operating with bandwidths in the 3-5MHz range or higher. So if that's
During Austin meeting majority of people in the jitter subgroup stated
they don't want to make the change. I don't disagree with your
statement
regarding majority of receivers have bandwidth higher than MJS
Baudrate/1667.
The baudrate/1667 today is entrenched and IB has already defined and
some
SerDes would operate dual speed. Changing the Bandwidth this late will
impact some SerDes.
Historically some of FC/GBE SerDes had high bandwidth receivers often
to overcome their high jitter peaking. I am not sure this is the
best approach anyway.
> the case, why not change the spec to reflect what people are doing? If
> today's receivers are able to track all that low frequency jitter, why
> do we want to unnecessarily force the transmitter designers to
> over-design their circuits? Bottomline is that if receivers are able to
> track low frequency jitter, the transmitters should be be to transmit
> the low frequency jitter without affecting system performance. Agilent
> is not proposing anything drastic or exclusionary. Given that a
> receiver with a higher bandwidth performs better than one with a lower
> bandwidth, people will naturally try to implement receivers with as high
> a bandwidth as feasible. And from our experience as well as from what
> other people in the industry are saying, a reasonable bandwidth for
> receivers today is 3-5MHz, which is what Agilent is proposing to move
> the "break" frequency to. This will not exclude anybody's design and it
> will certainly ease the design of transmitters, which is good for
> everybody, old players as well as young startups. In addition, it'll
> increase the level of integration possible, which again is good for the
> industry. I really do not see any downside to this proposal,
> techincally or economically.
As a designer you can still design your SerrDes for whatever bandwidth
you wish. Increasing the bandwidth only relaxes jittery transmitters
and effectively reducing user margin assuming most receiver have higher
bandwidth. I don't see how the level of integration can be increased
substantially by doubling the frequency.
>
> I disagree with your second point. If you look at Annex G of the Fibre
> Channel MJS document, you'll find the derivation of Fc/1667. Sonet
> defines the upper corner frequency to be baud rate divided by 2500. It
> also specifies that the amplitude of the sinusoidal jitter to be applied
> above this frequency is .15UI. And below this freqency, the applied
> jitter shall increase 20dB/decade. Fibre Channel specifies that for
> high frequencies, the amplitude of the sinusoidal jitter shall be
> .10UI. If you extend the line with the slope 20dB/decade until you hit
> the .10UI horizontal line, you'll get Fc/1667. This is more clearly
> document in the MJS document(Rev10, 6/9/1999) which can be obtained at
> www.t11.org. A similar calculation as the one you shown is also
> provided in the MJS document. However, that calculation is a check of,
> not a basis of, the break frequency numbers. If I recall correctly, the
> annex showed that with the "break" frequencies as chosen, the 100ppm
> constraint on the RefClk will not violate them. And if you look at
> Agilent's presentation from the Austin meeting, making the change will
> not violate the 100ppm constraint on RefClk either.
About 3 years ago I also proposed to FC MJS to increase the bandwidth
for the same reason your are proposing today. The MJS group did not
accept my proposal and I went back and fixed my jittery transmitter.
If we start making changes for comfort I am not sure where we will end.
Is the specification broken?
IEEE D2 accepted?
Should we make a change now?
Thanks,
Ali Ghiasi
Broadcom
>
> Regards,
>
> -Allan
>
> Mike Jenkins wrote:
> >
> > 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 |_____|
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~