Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: XAUI jitter tolerance




Hi Ali,

Please see my comments below.



Ali Ghiasi wrote:
> 
> 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.
> 
==================

If you don't disagree with my point that most receivers have bandwidths
beyond fc/1667, then I don't see what the problem is? The proposal will
not impact those receivers anyway.  And the transmitters.  Well, if the
early implementations meet the current spec, then they will have no
problems with meeting the new proposal.  In fact, they will have
"better", but unmeasureable, performance than those allowed by the new
proposal.  Can you elaborate how this change 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.

============
If you assume that each XAUI implementation only needs one transmitter,
then increasing the frequency will not increase the level of
integration.  However, if you look at the very real possibility that
that may not be the case and say for example, you need a transmitter for
every 2 to 4 receivers, then we are talking about a lot of transmitters
for the bigger chips.  And the savings somes from the fact that we can
lower the PLL cap on the transmitter, just as we have done on the
receiver.  Keep in mind that PLL caps, as far as I know, need to be
linear.  And these are the kind of caps that take the most area.  So a
reduction in the cap will save a lot of area.

===============


> >
> > 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.
> 

=================

Fortunately for us, we do not have a jittery transmitter problem.  Plus
it would be completely unethical for us to be making this proposal under
the false pretense of benefitting the industry when it is only to
qualify our own parts.  Agilent is not that kind of company! We are
looking for two things with this proposal: 1) consistency between the
spec and current implementations of functional systems.  Consistency
will lead to simpler and cheaper implementations.  2) higher level of
integration.

==================

> 
> Should we make a change now?

==================
YES.  Because of the reasons I have presented, I believe that we should
change it.  There is no better time to change it than with a new
standard.  We don't have to be permanently entrenched in this spec,
which even you agree, 3 years ago, needs to be changed.  The MJS group
probably took other factors into consideration when they rejected your
proposal.  Well, XAUI does not carry any old baggage that needs to be
considered.  It only needs to concern itself with the future and that is
precisely what our proposal attempts to do: guarantee that integration
will be easy and cheap in the future.



Regards,

-Allan



> 
> 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      |_____|
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~