| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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