RE: XAUI AC coupling
I would agree with Ed. DC coupling requirements can be system specific. As
such could be quite restrictive to board design efforts, especially from
host board to transceiver module interfaces.
From a transceiver module perspective, I would recommend AC coupling. In
fact usually will attempt to include the coupling caps in the module as an
added form of integration.
I have some anxiety about the prospect of DC coupling becoming a design
consideration for transceiver module implementation. I would strongly
oppose a DC coupling spec for XAUI.
Regards,
Chris Simoneaux
-----Original Message-----
From: Ed Grivna [mailto:elg@xxxxxxxxxxx]
Sent: Tuesday, September 26, 2000 3:05 PM
To: elg@xxxxxxxxxxx; tomp@xxxxxxxx
Cc: stds-802-3-hssg@xxxxxxxx; rtaborek@xxxxxxxxxxxxx
Subject: Re: XAUI AC coupling
Hi Tom,
I agree with the consideration, that IF we are to standardize a
DC coupled interface, then it is required to also spec the levels.
I think my main concern is that as soon as you do this, you will
open a Pandora's box of technologies that do not interoperate
at a DC level, but work fine when AC-coupled. For my own part,
would love to specify DC lvels, just so long as they match up
with the DC-levels _I_ want. If anything else goes in, escpecially
this late in the game, I'll be one of the first to scream restraint
of trade.
As stated earlier, I have no problem with allowing DC-coupling, but
I don't want it to be mandatory. However, once you spec the levels
in the standard, you now have requirements that must be met.
-Ed Grivna
> All,
> I concur that it would be advantageous to support both AC and DC
> coupling. Maybe we have a section with AC coupling specs and a separate
> table for DC coupling specs. This would allow a vendor to be just AC
> compliant or just DC compliant or both. If we leave out the DC specs all
> together (respectfully disagreeing with my fellow Minnesotan) than I
> don't think we have standardized anything for the DC coupled interfaces
> and we will not have interoperability.
>
> Tom
>
>
> Ed Grivna wrote:
> >
> > Hi Rich,
> >
> > I agree with the Dawson implementation; i.e., where capability for
> > AC-coupling is mandatory, and you CAN DC-couple if both ends
> > will support it.
> >
> > But in that regard, I don't believe it apporpriate to add ANY
> > DC-level numbers to the standard for XAUI signaling, not even as
> > a guideline. This places the responsibility on the implementer
> > (where it always belongs) to ensure that the devices they choose
> > will support DC-coupling (if they wish to implement it).
> >
> > The other place I find a minor dissagrement is with your statement
> > that if both ends of the link are made by the same manufacturer
> > that a DC-coupled link will generally be possible. This is not
> > necessarily the case, especially when CML drivers are used. These
> > switch very close to the power rail, and are not generally positioned
> > in the middle of the common mode operating range of the receiver.
> > While a DC-coupled connection MAY work, it is not optimal.
> >
> > Regards,
> >
> > Ed Grivna
> > Cypress Semiconductor
> >
> > >
> > > All,
> > >
> > > By my count, I have 4 votes for allowing XAUI DC-coupling against 0
> > > votes for requiring only AC-coupling. The 4 votes are:
> > >
> > > Ed Grivna - Cypress
> > > Dawson Kesling - Intel
> > > Jeff Porter - Motorola
> > > Rich Taborek - nSerial
> > >
> > > Any other opinions out there?
> > >
> > > Best Regards,
> > > Rich
> > >
> > > --
> > >
> > > "Jeff Porter (rgbn10)" wrote:
> > > >
> > > > Folks,
> > > >
> > > > I feel consensus emerging here.
> > > >
> > > > Rich writes
> > > >
> > > > > a) A XAUI implementer can always get away with AC-coupling and
> > > > > AC-coupling details for XAUI are readily available;"
> > > >
> > > > and
> > > >
> > > > > That said, I'd be happy to go with (1) or (2).
> > > >
> > > > Dawson writes
> > > >
> > > > > An alternative is to mandate CAPABILITY for AC coupling. This
allows
DC
> > > > > coupling where compatible implementations permit, but ensures that
ALL
> > > > > implemenations will interoperate via AC coupling.
> > > >
> > > > I agree. Specify the differential signal. Require the receiver
> > > > to function *when* driven by ac coupled signals to provide a method
> > > > that insures interoperability. After all, we've increased baud
rate,
among
> > > > other reasons, to permit ac coupling as an approach to
interoperability.
> > > > Do not require ac coupling since dc coupling will often work, and
we've
> > > > left a way to interoperate.
> > > >
> > > > The remaining technical work is to include in an (informative) XAUI
link
> > > > budget (if we choose to explain how this could work) the
attenuation,
> > > > skew, and jitter, etc. budgeted for ac coupling.
> > > >
> > > > Proposals and justification for this budget item?
> > > >
> > > > Jeff
> > > >
> > > > Rich Taborek wrote:
> > > > >
> > > > > Dawson,
> > > > >
> > > > > In terms of specsmanship, I believe that we have two alternatives
with
> > > > > regard to coupling for XAUI:
> > > > >
> > > > > 1) Leave coupling out altogether as an implementation detail;
> > > > > 2) Specify detail for both AC-coupling and DC-coupling.
> > > > >
> > > > > It sound like you're leaning towards (2) where I'm leaning towards
(1).
> > > > > My argument is that (2) is a whole heck of a lot more work than
(1)
and
> > > > > may be more costly since compliance verification has some non zero
cost.
> > > > > I believe that (1) works and is interoperable because:
> > > > >
> > > > > a) A XAUI implementer can always get away with AC-coupling and
> > > > > AC-coupling details for XAUI are readily available;
> > > > > b) A savvy XAUI implementer may save $$$, increase reliability
(fewer
> > > > > components), increase signal fidelity (fewer vias), etc. by going
with
> > > > > DC-coupling if possible given their component selection.
> > > > >
> > > > > The only other possibilities are not palatable to me:
> > > > >
> > > > > 3) Mandate AC-coupling;
> > > > > 4) Mandate DC-coupling.
> > > > >
> > > > > That said, I'd be happy to go with (1) or (2).
> > > > >
> > > > > Best Regards,
> > > > > Rich
> > > > >
> > > > > --
> > > > >
> > > > > "Kesling, Dawson W" wrote:
> > > > > >
> > > > > > Rich and all,
> > > > > >
> > > > > > I agree that it would be nice to avoid AC coupling if we can
still
> > ensure
> > > > > > interoperability.
> > > > > >
> > > > > > If we remove reference to coupling altogether, we must add a
common
mode
> > > > > > specification or definite logic levels; we cannot only specify
> > peak-to-peak
> > > > > > swing as we are now doing and expect interoperability. (All
chip-to-chip
> > > > > > interconnect spec's I know of specify either DC-referenced logic
levels
> > or
> > > > > > common mode and differential mode levels. Is there an exception?
We
have
> > > > > > avoided this by mandating AC coupling up to this time.)
> > > > > >
> > > > > > An alternative is to mandate CAPABILITY for AC coupling. This
allows
DC
> > > > > > coupling where compatible implementations permit, but ensures
that
ALL
> > > > > > implemenations will interoperate via AC coupling.
> > > > > >
> > > > > > -Dawson Kesling
> > > > > > Intel Corporation, NCD
> > > > > > 916 855-5000 ext. 1273
> > > > >
> > > > > -------------------------------------------------------
> > > > > 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
> > >
> > > -------------------------------------------------------
> > > 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
>