Re: XAUI jitter tolerance
Allan,
I agree with Mike Jenkins' analysis of maintaining the fc/1667 break
frequency spec for XAUI. I also agree with the current "problem free"
usage of this spec, as proposed in the T11 MJS Technical Report, for
Gigabit Ethernet 1000BASE-X, Fibre Channel 1G and 2G devices and
InfiniBand 2.5G devices. My rationale for voting on the prevailing side
of the very lopsided straw poll result to not pursue a change to the
implicit fc/1667 break frequency spec for XAUI is that insufficient
technical evidence has been provided to convince me that a change is
warranted. Previously, in a not on this thread aired over the Serial PMD
reflector, Tom Lindsay of Vixel and Mike Jenkins, among others pointed
to very clear and concise documentation of exactly how this value was
chosen for Fibre Channel originally. That documentation is available in
ftp://ftp.t11.org/t11/member/fc/jitter_meth/99-151v2.pdf. See Annex G
entitled: "Choosing the Corner Frequency: fc/1667" on page 94 (PDF 103)
of this document. I would be willing to change my vote if it can be
proven that the analysis provided in Annex G is erroneous and/or not
applicable to XAUI.
Please also see my additional comments below:
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.
See MJS Annex G for the explanation. SONET uses fc/2500, not the same
break frequency as FC, GE and IB.
> 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.
I'm confused as to what exactly is being limited by the fc/1667
specification. Are higher bandwidth receivers somehow precluded from
being compliant with this spec?
> 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.
It had been pointed out by Mike Jenkins and Tom Lindsay in earlier notes
on this thread that: "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." I'm having a hard time
convincing myself that changing the current fc/1667 break frequency will
drive down the cost of XAUI ports if the CDR circuitry, clearly among
the most complex XAUI circuitry, has to dissipate more jitter.
> 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 wholeheartedly agree with achieving high levels of XAUI integration
and efficient PLL designs allowing high levels of integration. I don't
agree that leaving the break frequency where it is prevents an increase
in receiver bandwidth. Therefore, it seems that you are free to use a
smaller PLL filtering cap.
> 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.
XAUI, and its 3.125 Gbps line rate is fairly new. XAUI virtually must be
implemented in CMOS because of the multiple lanes, embedded CODECs and
lane coordinating logic. Many vendors are making great progress with
XAUI and it's even showing up in FPGAs! I believe that many who voted as
they did in the straw poll in December were informed and cognizant of
the decision they were making. Similarity with other standards was not
an issue in my vote. Confidence in the MJS work and the folks involve in
that effort was a deciding factor in my vote and I stand by it.
Happy Holidays,
Rich
--
> 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
-------------------------------------------------------
Richard Taborek Sr. Phone: 408-845-6102
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Fax: 408-845-6114
2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com