|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
Rich & all,
You may count my vote as mandatory SUPPORT for AC coupling.
WHAT THAT MEANS is that input circuits have a weak DC bias generator such that if you DO use AC coupling, then a SERDES-style terminator for a transmission line trace will put the DC bias point at the optimum point for the ASIC.
By SERDES-style terminator I mean that for a differential pair (assuming 50 Ohm lines) you have two 50 Ohm resistors with one attached to each input. The resistors are tied together at the other ends to give 100 Ohms differential impedance, and this center tap is AC grounded. This has evolved into the "standard" terminator for SERDES inputs at 1 and 2.5 Gb/s.
This _allows_ you to AC couple from the driving ASIC and lets the receiver input bias itself to its favorite DC common mode level.
Now I would expect that this would be used for either long trace runs (transmission line rules) or where you need to have plug-in interchangeability, like, for optical transceivers, like.
BUT, if you are looking at a short ASIC-to-ASIC interconnect, then you could let the driving ASIC's outputs overwhelm this weak bias generator and set the DC levels if they are appropriate (i.e., compatible chips). Thus, for a densely packed board you could do without AC caps, series terminators and everything else if you are within the trace lengths where lumped parameter rules apply.
You get the best of BOTH worlds. Optimal performance if and when you use AC coupling and also DC coupling if the chips mate up and you need minimal parts count.
What's so darned hard about this? The 1.25/2.5/3+ Gb SERDES technology chips and ASICS _already_ do it! It works COOL!
From: Rich Taborek [SMTP:email@example.com]
Sent: Tuesday, September 26, 2000 11:58 AM
Subject: Re: XAUI AC coupling
Reading between the lines, I count your vote at For Mandatory
AC-coupling for XAUI. Tell me if I'm wrong.
One issue I have note addressed is where the capacitors go for
AC-coupling. You mentioned that your product requirements dictated that
transceiver modules connected to ASICs via serial links had capacitors
inside the Transceiver module. I'd like to point out the following with
respect to XAUI capacitors, if they're required by P802.3ae:
1) XAUI capacitors will likely be external to XAUI ASICs. My basis is
that the optimum capacitor value is far too large for a common CMOS
process, a process likely to be employed for most XAUI devices due to
other considerations such as power consumption.
2) If XAUI capacitors are required, there will be a minimum of 16 of
them for each XAUI link. That only accounts for one per differential
signal. If the logistics are such that, for interoperability, it is not
straightforward to determine whether a capacitor exists on the transmit
or receive side, 32 capacitors may be employed per XAUI link. It's a bit
of a stretch, but if some XAUI transceiver modules include internal
capacitors and some don't, up to 36 capacitors may be employed per XAUI
link (PS. Make sure you have plenty of capacitors in stock so you'll be
able to ship equipment in the wake of capacitor shortages such as the
famous shortage of early '00 :-). This is not my area of expertise, but
I'm wondering about the impact of the six PCB via's, capacitors,
reliability, etc. will be on XAUI links if the standard mandates
> Larry Miller wrote:
> From a user:
> This looks like a replay of the Transceiver/SERDES mess on 100 Mb/s
> SFF and 1G 1 x 9 systems.
> What happened there was that nobody agreed on the input common-mode DC
> level of either direction. Users were lectured to about "classic" PECL
> coupling networks by companies whose own wares did not follow it.
> Bipolar chips wanted a different DC input level from CMOS chips, which
> was again different from GaAs designs.
> Worse, in many cases the transceiver inputs relied on the Thevenin
> coupling network to set the (correct) DC bias point.
> The net result was that many transceiver/SERDES combinations did not
> operate together at all. In the end, vendors ended up having to build
> two versions of everything-- AC coupled and DC coupled. And there were
> still incompatible combinations.
> We ended up insisting on AC coupled designs for everything just to get
> interchangeability of parts between vendors, time, temperature, phase
> of the moon, etc. And we also ended up insisting that the transceivers
> have the caps IN the units, where they belong from an EMI standpoint.
> I suspect that our company will again insist on capability for AC
> coupling. That way each vendor gets to control the DC characteristics
> on "his" side of the coupling capacitor. The corollary here is that
> each vendor is responsible for providing an input circuit bias means
> that sets the DC level to the "sweet spot" for that chip.
> Larry Miller
> Nortel Networks
> -----Original Message-----
> From: Rich Taborek [SMTP:firstname.lastname@example.org]
> Sent: Saturday, September 23, 2000 12:43 PM
> To: HSSG
> Subject: Re: XAUI AC coupling
> 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 detail to select either AC or DC-coupling in the
> latter scenario. The standard should not dictate sub-optimal
> 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,
> Vipul Bhatt wrote:
> > Rich,
> > Let's see if we can refine the question, in the hope of making
> > We do have some common ground: If a PHY module is going to be
> > by a switch manufacturer, it will likely end up as a pluggable
> > solderable module, at the XAUI interface. To manage the
> > buyer-supplier scenarios, it is best to use AC coupling. If,
> however, a
> > PHY module is going to be integrated by the switch manufacturer
> on a
> > single board, then XAUI becomes the switch manufacturer's
> internal design
> > responsibility, and they should have the freedom to choose DC
> or AC
> > coupling. Just as it would be wrong to burden a pluggable
> module with
> > mandated DC coupling, it would be wrong to burden an integrated
> > board design with mandated AC coupling.
> > Beyond this common ground, where we go from here becomes an
> > choice. One approach would be to leave the coupling issue to
> > implementers. Another approach would be to say, the popular
> purpose of
> > XAUI is to allow easy separation of switch and PHY module
> > responsibilities, and to allow the implementation of pluggable
> > solderable PHY modules. To help achieve that purpose in a
> > fashion, we should mandate AC coupling. This is the "majority
> gets its
> > way" approach. At the moment, I favor the second approach. To
> > further progress, it will help to know what others think.
> > Regards,
> > Vipul
> > email@example.com
> > (408)542-4113
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@nSerial.com
Santa Clara, CA 95054 http://www.nSerial.com