RE: XAUI AC coupling
Ed,
If we specify that DC coupling is allowed, but don't specify DC levels,
we are not specifying a compatibility interface. DC proprietary
implementations
are allowed because XAUI is optional. Keep XAUI a compatability interface -
specify it as AC. Don't weaken 802.3ae's specification by specifying an
interface that doesn't provide compatabilty. Don't put in DC levels
that will restrict future technology or, if we follow Ali's suggestion,
will require some implementations to have double AC coupling.
Pat
-----Original Message-----
From: Ed Grivna [mailto:elg@xxxxxxxxxxx]
Sent: Wednesday, September 27, 2000 12:29 PM
To: rtaborek@xxxxxxxxxxxxx; aghiasi@xxxxxxxxxxxxx
Cc: stds-802-3-hssg@xxxxxxxx
Subject: Re: XAUI AC coupling
>
> Hi
>
> There is already another Standard based on Hari, which specifies both AC
> and DC coupling.
> I agree majority of applications will be AC coupled, but there are some
> applications which
> require DC coupling. We should spec AC coupling and as ED said in a
> section describe how to
> implement DC coupling. The other standard already has chosen 0.75 volts
> of common mode, so we
> should choose 0.75 V.
>
> Ali Ghiasi
> Newport Comunication
Ali, watch what words you use. I never said this. While I do think that
DC coupling should be ALLOWED, I do not think the specific levels should be
specified. As I explicitly stated earlier, as soon as you start to pick
levels that are not what I want, I will be alllllll over you. Even
if you DO pick levels that I might want, this could be very limiting on
future implementatoins that want to make use of this interface. By
fixing a DC-level now, you may limit the future uses of the standard.
For example (and I'll be a little outrageous here to get my point
across), if a company makes a TX that outputs the proper AC amplitues
but does so with a signal that is 1V BELOW ground, and it also makes
a receiver that can also accept these same levels below ground, the
fixing of a DC-level above ground in the standard would prohibit the
interconnection of these devices as a DC-connection, even though they
are fully DC-compatible with each other.
If we went along with the "plan" you have devised here, only the chosen
few that match up to your "selected" levels would be allowed to implement
DC-coupled connections. What I have stated, and will continue to do,
is that a DC-coupled connection should be allowed, but with the
specific requirements of this implementation controlled by the
implementer, not be the standard. If the implementer can't understand
the words on the datasheets for the parts he's using, thats his/her
problem. DC-coupling should be an implementaion decision, not a
requirement.
I'm not the first one to state this, and we both know its true. As soon
as you put a DC signal-level in the spec, even if its optional, it
becomes a requirement. As a requirement, it may reduce the number
of players in the game, which should not be a goal of the standard.
The standard should document what is required for interoperability, and
to ensure a robust design. Anything more than this, is restraint of
trade.
-Ed Grivna
>
>
> Rich Taborek wrote:
> >
> > Tom, Ed,
> >
> > I agree with this direction and side with Ed on the issue of spec'ing
> > DC-coupling for the reasons that Ed provides. Thanks for your support on
> > this issue.
> >
> > Best Regards,
> > Rich
> >
> > --
> >
> > Ed Grivna wrote:
> > >
> > > 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