Re: XAUI AC coupling
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