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

RE: XAUI AC coupling




Rich,

I am at a loss as to what is going on here.

For example, Vipul mentioned that a key application for XAUI was in a logic
chip to transceiver interface. You stated that this was never intended to be
within the scope of the standard and that XAUI would find itself in
applications such as a directly driving a laser. If there was ever an
"application" that the standard didn't intend to standardize....

Let's make this simple: there are two ways to look at this question. Either:

1. The inclusion or exclusion of the specification of AC coupling does not
impact, in any way, other REQUIRED specifications for this interface. The
specification is therefore purely optional and can be put in, or not, as a
matter of convenience (either the convenience of the draft writers or the
convenience of the users or whomever). In cases like this, I personally like
to side with the customers.

2. The specification does impact other technical decisions. This is more
complicated. Usually, these discussions ultimately come back to a discussion
of the objectives. Rather than end up here, I would start here. It is my
belief that the original purpose of the XAUI interface (HARI etc) was to be
an optional common interface between the MAC and the PHY (as described in
the standard) and the LOGIC (MAC + part of the PCS) and the TRANSCEIVER in
many applications. If this is true, the decision should be made to optimize
this application.

jonathan

p.s. Regarding my questions from before, my uneducated perspective (based on
work on the OLC, OLM, GBIC, and SFF specifications and work with customers)
is:

1. What is the impact of this decision on parts that operate at different
voltages and use different technologies (e.g. a "MAC Chip and a WDM
Transceiver")? Yes, I reject the assumption that these could and should use
the same technology. Answer: the impact is significant and lack of industry
consensus makes for sub optimized designs as board designers attempt to
support both.
2. What is the impact of this decision on low jitter design? Answer: a long
time ago I was informed that AC coupling provided a number of benefits to
the chip designers and made it easier to design low jitter drivers, in
particular. This should be something that that can be confirmed.
3. What is the impact of this decision on EMI generation at the board level?
Answer: Any part on the board radiates energy. Bad.
4. What is the impact of this decision on signal integrity? Answer: Good and
bad. Wish Howie Johnson was here.... Components can't help the signal
integrity of the transmission line. They can help the design of the
driver/receiver.
5. What is the impact of the ground differentials common between high power
boards in a system? Answer: should never be -- and no designer would ever
admit to it -- but, can be significant. 
6. What else am I forgetting to ask? Implications of bias circuits (RX
side), external vs internal impedance matching devices (and the tolerance
thereof), etc.

> -----Original Message-----
> From: Rich Taborek [mailto: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
>