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

Re: XAUI AC coupling




Jonathan,

Please allow me to simplify this discussion. If I offer a customer an
XGMII extender consisting of two XGMII-to-XAUI chips, I would likely
offer the customer two of my chips rather than one of mine and the other
from a third party. The two chips are likely to support DC-coupling by
the mere fact that they're the same chip. This is clear proof of XAUI
DC-coupling. I don't know where you're headed with your argument of an
AC-coupling requirement. I'm merely stating that XAUI, an XGMII
extender, should allow DC-coupling. Therefore, the converse is true: The
P802.3ae standard should not require AC-coupling. It's as simple as
that.

Let's quit beating around the bush. I've already put up the challenge.
If it can be proven that AC-coupling is required for XAUI
interoperability, I'll back down and change my tune. I've discussed this
issue within nSerial and with outside experts before posting my initial
note. I achieved 100% agreement to not requiring AC-coupling for XAUI in
the standard.

The only question that should remain is whether both AC and DC coupling
should be specified in clause 47. I've addressed this issue in a prior
note on this thread in response to Dawson Kesling. 

I'll try responding to some of your other questions below. Am I
qualified? ...only as a novice in this area. How does a novice become an
expert? ...by sticking their neck out and getting it hacked at by the
experts :-O 

Jonathan Thatcher wrote:

> Rich,
> 
> If mine is twisted, yours is a full double helix :-) Let me demonstrate.
> 
> If the cap is not required and can be proven so by not proving otherwise, we
> must have specified a set of logic levels that guarantees that there is
> little or no common mode offset between chips. Why not, then, specify a cap
> and ask to have someone prove that the common mode offset specification is
> required? Can't prove it? Then we should reject a 0.75 common mode voltage.
> Sound absurd? I agree.
> 
> Please note, I am not taking a position on the choice. I don't feel
> qualified to do so. There are many reading this that are much more qualified
> that I (we?).
> 
> The point is that you win an argument by first establishing the assumptions.
> I, for one, have not YET accepted yours.
> 
> So, a few questions for those "in the know:"
> 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.

The decision I propose is to allow either AC or DC coupling as an
implementation decision not a standard mandate. Parts that operate at
different voltages and use different technologies would likely be
AC-coupled.

> 2. What is the impact of this decision on low jitter design?

I suspect that DC-coupling, if possible, is superior since the
interconnect is simpler.

> 3. What is the impact of this decision on EMI generation at the board level?

Probably negligible.

> 4. What is the impact of this decision on signal integrity?

I suspect that DC-coupling, if possible, is superior since the
interconnect is simpler.

> 5. What is the impact of the ground differentials common between high power
> boards in a system?

None. If a significant ground differential condition exists, use
AC-coupling.

> 6. What else am I forgetting to ask?
> 
> jonathan
> 
> > -----Original Message-----
> > From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
> > Sent: Friday, September 22, 2000 3:49 PM
> > To: HSSG
> > Subject: Re: XAUI AC coupling
> >
> >
> >
> > Jonathan,
> >
> > I can best describe your response as "twisted".
> >
> > XAUI is an optional interface for P802.3ae. I don't believe
> > that I will
> > get any disagreement on this point. However, 802.3 voters voted
> > unanimously to include XAUI as a baseline proposal in P802.3ae. The
> > definition of XAUI in the standard has been allocated a clause,
> > specifically, clause 47.
> >
> > We (P802.3ae) need to develop XAUI specs. The ones in the baseline
> > proposal are a good start but are far from complete. If you
> > were at the
> > New Orleans XAUI breakout session, and I believe you were for a short
> > time, you would have a good idea of how incomplete the XAUI
> > specs really
> > are. One of the issues at hand is one of Tx and Rx coupling method.
> > Recent reflector discussion is already talking about the possible
> > specification of capacitor values for XAUI AC-coupling.
> >
> > I'm taking my usual systems perspective and trying to have a serious
> > technical discussion on the issue of the requirement of a specific
> > coupling method for XAUI. I believe that this TECHNICAL discussion is
> > both appropriate and warranted. My point is that XAUI
> > AC-coupling is NOT
> > required for interoperability. Therefore, it should not be a
> > requirement
> > in the standard. Such a requirement, if any, would be listed
> > in the PICS
> > of clause 47. I don't believe that asking for proof of an AC-coupling
> > requirement for XAUI is extreme at all. This proof is in line with the
> > PAR 5 Criteria and the KISS principle, some of the basic
> > tenets by which
> > 802.3 has historically made decisions and made its standards so
> > successful.
> >
> > As further proof of the wishy-washy nature of the XAUI
> > "requirement" to
> > AC-couple I will submit a presentation by Ali Ghiasi on this issue:
> > http://grouper.ieee.org/groups/802/3/10G_study/public/nov99/gh
> > iasi_1_1199.pdf.
> > See slide 6 where the AC coupling caps are shown and accompanied by an
> > asterisk which reads:
> >
> > * It is recommended were possible to use 0.75V for the common mode
> > voltage
> > to allow the user for possible direct connect in backplane
> > applications.
> >
> > Well, fact of the matter is that XAUI is ONLY a backplane (i.e.
> > chip-to-chip) application. There is no objective in P802.3ae to extend
> > XAUI with copper cables between equipment which is likely powered by
> > different supplies. Therefore, even the original Hari presentations
> > suggest that DC-coupling is appropriate for XAUI.
> >
> > Lets please keep this discussion above board and on a
> > technical level so
> > we have a chance of finishing this standard on time.
> >
> > Best Regards,
> > Rich
> >
> > --
> >
> > Jonathan Thatcher wrote:
> > >
> > > Rich,
> > >
> > > While the discussion is worth having and your request for supporting
> > > information valid, I think that your conclusion that we
> > must prove that it
> > > is required for interoperability a bit on the extreme side.
> > There are lot's
> > > of things that we add to the standard, that have
> > significant value, that are
> > > not required for interoperability. For example: XAUI.
> > >
> > > jonathan
> > >
> > > > -----Original Message-----
> > > > From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
> > > > Sent: Friday, September 22, 2000 11:57 AM
> > > > To: HSSG
> > > > Subject: Re: XAUI AC coupling
> > > >
> > > >
> > > >
> > > > All,
> > > >
> > > > I'd like to propose that clause 49, XAUI, remove any
> > requirement for
> > > > coupling, AC or DC. The basis of this proposal is as follows:
> > > >
> > > > 1) XAUI is a chip-to-chip interconnect. As such, DC-coupling is
> > > > clearly appropriate and advantageous from an implementation
> > > > perspective, an example is when interfacing chips from like
> > > > logic families utilizing the  same power supplies. This is likely
> > > > to be the case in many implementations. Therefore, the standard
> > > > should not dictate AC-coupling when DC-coupling is adequate to
> > > > achieve interoperability.
> > > >
> > > > 2) I've reviewed all instances of the use "coupling"
> > including fuzzy
> > > > variants in the 802.3 standard. There is no precedent for
> > dictating a
> > > > specific coupling method for a chip-to-chip interconnect in the
> > > > standard.
> > > >
> > > > 3) Absolutely nothing will be taken away from the standard by
> > > > removing a requirement for AC-coupling. If AC-coupling is either
> > > > desired when not required or required for a specific
> > implementation,
> > > > then the details for AC-coupling including the determination of
> > > > specific capacitor values,  the frequency spectrum of 8B/10B
> > > > transmission code, etc. are all well  documented and
> > readily available.
> > > > 8B/10B transmission code is far and away the most
> > commonly used and
> > > > well understood code in serial gigabit links including
> > chip-to-chip
> > > > interconnects. From a signal coupling  perspective, except for
> > > > proportionally higher signaling frequency, there is no difference
> > > > between a single XAUI lane and a 1000BASE-X link. Note that for
> > > > 1000BASE-X, both AC and DC coupling is available from
> > > > transceiver module vendors.
> > > >
> > > > AC coupling was proposed as a requirement for the Hari
> > interface which
> > > > was effectively renamed as XAUI. It has been carried into
> > the baseline
> > > > proposals for P802.3ae. Now is the time to decide whether
> > AC-coupling
> > > > is an interoperability REQUIREMENT. I challenge anyone to
> > argue and
> > > > prove that AC-coupling is required for XAUI
> > interoperability. If such
> > > > proof is not forthcoming, clause 49 should be modified to
> > remove any
> > > > requirement for AC-coupling.
> >
> > -------------------------------------------------------
> > 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
> >

-- 

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