RE: XAUI AC coupling
Hi
XGP is one possible implementation, but there other cases where you may have
an interface requiring AC caps. My suggestion is to require adding AC caps
at the electrical receiver.
Why on the receive side? to protect the high speed receiver input. In
addition AC caps are often required with most laser driver design to meet
laser safely. This mean on the XGP the optical transmitter input will have
AC coupling an there will be no AC coupling at the output of the optical
receiver.
Thanks,
Ali Ghiasi
Newport Comunication
------Original Message------
From: Chris Simoneaux <csimoneaux@xxxxxxxxxxxxx>
To: HSSG <stds-802-3-hssg@xxxxxxxx>
Sent: September 29, 2000 5:14:13 AM GMT
Subject: RE: XAUI AC coupling
Rich,
Thanks for the summary. Your assessment is compelling and the "stretch" you
speak of is valid. However, I also believe that the intention should be
that the industry converge on common footprint (e.g. XGP). The footprint
will dictate where AC coupling resides. It would be less painful for multi
vendor spec developments for the AC coupling to be dictated.
Chris
-----Original Message-----
From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
Sent: Tuesday, September 26, 2000 12:58 PM
To: HSSG
Subject: Re: XAUI AC coupling
Larry,
Reading between the lines, I count your vote at For Mandatory
AC-coupling for XAUI. Tell me if I'm wrong.
One issue I have note addressed is where the capacitors go for
AC-coupling. You mentioned that your product requirements dictated that
transceiver modules connected to ASICs via serial links had capacitors
inside the Transceiver module. I'd like to point out the following with
respect to XAUI capacitors, if they're required by P802.3ae:
1) XAUI capacitors will likely be external to XAUI ASICs. My basis is
that the optimum capacitor value is far too large for a common CMOS
process, a process likely to be employed for most XAUI devices due to
other considerations such as power consumption.
2) If XAUI capacitors are required, there will be a minimum of 16 of
them for each XAUI link. That only accounts for one per differential
signal. If the logistics are such that, for interoperability, it is not
straightforward to determine whether a capacitor exists on the transmit
or receive side, 32 capacitors may be employed per XAUI link. It's a bit
of a stretch, but if some XAUI transceiver modules include internal
capacitors and some don't, up to 36 capacitors may be employed per XAUI
link (PS. Make sure you have plenty of capacitors in stock so you'll be
able to ship equipment in the wake of capacitor shortages such as the
famous shortage of early '00 :-). This is not my area of expertise, but
I'm wondering about the impact of the six PCB via's, capacitors,
reliability, etc. will be on XAUI links if the standard mandates
AC-coupling.
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 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
-------------------------------------------------------
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