Re: XAUI AC coupling
Jonathan,
Don't be so lossy :-)
We're all working on a standard. The standard project is P802.3ae. The
goal of the project is to specify the architecture for 10 Gigabit
Ethernet devices.
XAUI is an optional part of P802.3ae. Now I'm going to quote verbatim
the text from Clause 47 (XAUI) related to XAUI applications:
"The purpose of the 10 Gigabit Attachment Unit Interface (XAUI) is to
extend the operational distance of the XGMII and to reduce the number of
interface signals. Applications include extending the physical
separation possible between MAC and PHY components in a 10 Gigabit
Ethernet system distributed across a circuit board."
"Application
This clause applies to the XGMII interface between the MAC and PHY. The
implementation of the XAUI interface is primarily intended as a
chip-to-chip (integrated circuit to integrated circuit) interface
implemented with traces on a printed circuit board. Where the XGMII is
electrically limited to distances of approximately 3 inches, the XAUI
allow extension of the XGMII to approximately 20 inches."
In the first paragraph of your latest response, you are decrying that I
am focusing on XAUI as a laser driver. Please note that in context I
view this as yet another XAUI application within a 10GE link, as
suggested by the wording of Clause 47. Furthermore, you are taking this
application out of context. For the sake of clarity, I will reproduce
the relevant paragraph below in its entirety:
(In response to Vipul Bhatt): "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."
It should be clear that XAUI applications include all of the following:
1) MAC-to-PHY Chip-to-chip interconnect;
2) MAC to transceiver module interconnect;
3) Intra-PHY chip-to-chip interconnect (e.g. retimer, retimer to laser
driver, etc.)
All the above applications are within the scope of XAUI. Dictating the
signal coupling requirements for all applications under the scope of
XAUI is not appropriate as the standard should not dictate sub-optimal
implementations.
Please see below for additional comments:
Jonathan Thatcher wrote:
>
> 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.
I've read the above paragraph 10 times and it makes less sense upon
every re-read. Please tell me what you're getting at in plain english.
The best interpretation I can come up with is that you're saying that
AC-coupling should be specified in Clause 47, but that is should be
optional. This would be my 2nd preference. Not specifying it at all is
first.
> 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.
What application? You mention MAC and PHY and LOGIC and TRANSCEIVER.
Perhaps a picture would be clearer. If you are trying to say that the
only XAUI application is one which has a Transceiver Module on one end,
then I disagree. This is only one of the XAUI applications my customers
are asking me for.
> 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.
This is ONE XAUI application for which AC-coupling is useful for
interoperability
> 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.
I find it hard to believe that sticking a capacitor, or two, or three,
and a bunch of via's in a XAUI link, where none may be required at all
from a signal matching perspective, will result in lower jitter or make
it easy to design low jitter drivers. This should definitely be
something that should 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.
So how is EMI related to AC or DC-coupling? I'd suggest dropping this
one unless anyone can come up with non negligible ties between the two.
> 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.
Key word: CAN. They MAY NOT. That's my point. Leave it to the
implementer to decide whether AC or DC-coupling is required.
> 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.
Again. Leave it to the implementer to determine the proper solution.
This isn't the only problem you're going to have if you have large
ground differentials between boards in a system. I'd keep a fire
extinguisher handy :-)
> 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.
Sound's like your grasping at straws. The implementer will be able to
gauge whether DC-coupling is possible (Rx bias). Impedance matching is
an unrelated subject. If you don't match your impedances, your XAUI link
won't work reliably regardless of how well you've implemented your
AC-coupling.
Bottom line: XAUI signal coupling should be left to the implementer. We
pay these guys the big bucks because they come up with robust optimized
designs, not designs forced to be suboptimal by a standard.
Best Regards,
Rich
--
> > -----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
-------------------------------------------------------
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