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

Re: XAUI AC coupling




Larry,

The standard needs to differentiate between a specific XAUI application,
such as an XGP Transceiver Module interface and XAUI in general. I
believe that your comments are applicable to a 10 Gigabit Pluggable
Transceiver Module.

Best Regards,
Rich
    
--

> Larry Miller wrote:
> 
> From a user:
> 
> This looks like a replay of the Transceiver/SERDES mess on 100 Mb/s
> SFF and 1G 1 x 9 systems.
> 
> What happened there was that nobody agreed on the input common-mode DC
> level of either direction. Users were lectured to about "classic" PECL
> coupling networks by companies whose own wares did not follow it.
> Bipolar chips wanted a different DC input level from CMOS chips, which
> was again different from GaAs designs.
> 
> Worse, in many cases the transceiver inputs relied on the Thevenin
> coupling network to set the (correct) DC bias point.
> 
> The net result was that many transceiver/SERDES combinations did not
> operate together at all. In the end, vendors ended up having to build
> two versions of everything-- AC coupled and DC coupled. And there were
> still incompatible combinations.
> 
> We ended up insisting on AC coupled designs for everything just to get
> interchangeability of parts between vendors, time, temperature, phase
> of the moon, etc. And we also ended up insisting that the transceivers
> have the caps IN the units, where they belong from an EMI standpoint.
> 
> I suspect that our company will again insist on capability for AC
> coupling. That way each vendor gets to control the DC characteristics
> on "his" side of the coupling capacitor. The corollary here is that
> each vendor is responsible for providing an input circuit bias means
> that sets the DC level to the "sweet spot" for that chip.
> 
> Larry Miller
> Nortel Networks
> 
>      -----Original Message-----
>      From:   Rich Taborek [SMTP:rtaborek@xxxxxxxxxxxxx]
>      Sent:   Saturday, September 23, 2000 12:43 PM
>      To:     HSSG
>      Subject:        Re: XAUI AC coupling
> 
>      Vipul,
> 
>      I'd like to set the record straight: Neither I nor anyone else
>      involve
>      in this thread has ever recommended mandatory DC-coupling. The
>      P802.3ae
>      approved XAUI baseline, developed initially by the Hari group
>      which
>      included experts from Ethernet, Fibre Channel and InfiniBand,
>      ended up
>      requiring AC-coupling. I have proposed removing this requirement
>      and
>      allowing either AC or DC-coupling. My reading of your first
>      paragraph
>      suggests that we are in violent agreement. If this is indeed the
>      case,
>      then the only remaining decision is whether AC and DC-coupling of
>      XAUI
>      is described in the standard or not. I'm happy going either way
>      on this.
>      I favor leaving the details to the implementer.
> 
>      In your second paragraph you seen to waver from violent agreement
>      and
>      note a very specific application of XAUI as a system ASIC to
>      transceiver
>      module link. I maintain that this specific application is well
>      outside
>      the scope of the standard and only representative of one of a
>      myriad of
>      applications for XAUI. For example, a simple early 10GE XAUI
>      application
>      is to couple the XAUI output directly to a laser diver and
>      post-amplifier set of a WWDM module. The XAUI interface is short,
>      the
>      laser driver to XAUI interface is likely to be custom, and
>      DC-coupling
>      is appropriate. As I have pointed out in prior notes, a prevalent
>      XAUI
>      application will be as a fixed chip-to-chip interconnect not
>      involving
>      optical modules at all. It is a straightforward implementation
>      detail to
>      select either AC or DC-coupling in the latter scenario. The
>      standard
>      should not dictate sub-optimal implementations.
> 
>      Vipul, I can't seem to place you in either the "Mandatory
>      AC-coupling"
>      or "Allowable AC or DC-coupling" categories. From your last note
>      it
>      seems like you're abstaining. I'd also like to get other's
>      perspective
>      on this issue.
> 
>      Best Regards,
>      Rich
> 
>      --
> 
>      Vipul Bhatt wrote:
>      >
>      > Rich,
>      >
>      > Let's see if we can refine the question, in the hope of making
>      progress.
>      >
>      > We do have some common ground: If a PHY module is going to be
>      purchased
>      > by a switch manufacturer, it will likely end up as a pluggable
>      or
>      > solderable module, at the XAUI interface. To manage the
>      multiple
>      > buyer-supplier scenarios, it is best to use AC coupling. If,
>      however, a
>      > PHY module is going to be integrated by the switch manufacturer
>      on a
>      > single board, then XAUI becomes the switch manufacturer's
>      internal design
>      > responsibility, and they should have the freedom to choose DC
>      or AC
>      > coupling. Just as it would be wrong to burden a pluggable
>      module with
>      > mandated DC coupling, it would be wrong to burden an integrated
>      single
>      > board design with mandated AC coupling.
>      >
>      > Beyond this common ground, where we go from here becomes an
>      interesting
>      > choice. One approach would be to leave the coupling issue to
>      the
>      > implementers. Another approach would be to say, the popular
>      purpose of
>      > XAUI is to allow easy separation of switch and PHY module
>      > responsibilities, and to allow the implementation of pluggable
>      or
>      > solderable PHY modules. To help achieve that purpose in a
>      bullet-proof
>      > fashion, we should mandate AC coupling. This is the "majority
>      gets its
>      > way" approach. At the moment, I favor the second approach. To
>      make
>      > further progress, it will help to know what others think.
>      >
>      > Regards,
>      > Vipul
>      >
>      > vipul.bhatt@xxxxxxxxxxx
>      > (408)542-4113
>      >
>      > ===============
>      >
>      > > -----Original Message-----
>      > > From: owner-stds-802-3-hssg@xxxxxxxx
>      > > [mailto:owner-stds-802-3-hssg@xxxxxxxx]On Behalf Of Rich
>      Taborek
>      > > Sent: Saturday, September 23, 2000 12:55 AM
>      > > Cc: HSSG
>      > > Subject: Re: XAUI AC coupling
>      > >
>      > >
>      > >
>      > > Vipul,
>      > >
>      > > OK, I asked for it... Now I'm forced to respond.
>      > >
>      > > A PHY module to ASIC connection, with the ASIC being in-line
>      and
>      > > eventually connected to a switch fabric, is very likely to be
>      a XAUI
>      > > implementation. If the module is pluggable, then it is very
>      likely that
>      > > the XAUI link would be AC-coupled to insure maximum
>      interoperability.
>      > > However, if the module is fixed, there are non negligible
>      cost,
>      > > reliability and performance advantages to employing
>      DC-coupling instead
>      > > if applicable. There is no risk. My point all along, is that
>      > > coupling is an implementation detail and should not be a
>      standard
>      > > mandate.
>      > >
>      > > Your PECL example reflects information an implementer should
>      be able to
>      > > glean from a manufacturers data sheet. Many XAUI devices will
>      be fixed.
>      > > The implementer simply reads the relevant data sheets for
>      both XAUI
>      > > devices and determines whether or not AC-coupling is
>      required. If
>      > > AC-coupling is not required, the implementer may choose to
>      DC-couple.
>      > > The determination of signal coupling requirements is standard
>      practice
>      > > for chip-to-chip interconnects.
>      > >
>      > > Your third paragraph seems to describe a scenario where an
>      implementer
>      > > makes a bad decision to employ DC-coupling where the device
>      specs for
>      > > the two XAUI devices employed in the link dictated
>      AC-coupling. I was
>      > > unaware that the purpose of the standard was to force
>      suboptimal
>      > > implementations in case an implementer misinterprets device
>      > > data sheets.
>      > >
>      > > I believe that most implementers would be incensed by such
>      imposing
>      > > regulations. I certainly hope that the same implementer
>      doesn't rely on
>      > > the standard for all other aspects of XAUI link
>      implementation, such as
>      > > power supply decoupling, trace layout, connector choice, via
>      design,
>      > > etc. to insure that their XAUI links work reliably.
>      > >
>      > > I don't understand the relevance of LVDS to this discussion,
>      please
>      > > explain.
>      > >
>      > > I agree that if either an implementer is uncertain about DC
>      bias or DC
>      > > bias itself is uncertain, that AC-coupling should be used.
>      However, you
>      > > seem to be describing a scenario where too much uncertainty
>      exists. It
>      > > is highly likely that the operation of the XAUI link will be
>      uncertain
>      > > in this case.
>      > >
>      > > To conclude, your assumed XAUI configuration is system ASIC
>      to
>      > > transceiver module which exemplifies only one possible XAUI
>      application
>      > > and one in which DC-coupling is applicable and preferred in
>      many
>      > > instances. In addition your desire is to impose suboptimal
>      > > implementations on all XAUI links in case an implementer
>      > > happens to make a mistake. I have to respectfully disagree
>      that either
>      > > argument dictates that XAUI AC-coupling is technically
>      required.
>      > >
>      > > Best Regards,
>      > > Rich

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