Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: Proposal: XGMII = XBI+



Title: Re: Proposal: XGMII = XBI+
Since you issued a call for "roger", I'll jump in with a comment.
 
I think you are forgetting the purpose for XGMII. If you want to continue down
the slippery slope of "improving" XGMII, you'll eventually end up with XAUI again.
 
XAUI is supposed to be the high-tech, move the signals around 18" or more,
use minimal pins, gee-whiz interface that people can put into their ASICs.
XGMII is supposed to be the straightforward interface that can be driven by
FPGAs over an inch or two.
 
156 MHz, double-pumped, is already pushing the envelope. I'm trying to build a
test-pattern generator today for XGMII and the number of non-ASIC options
is already very small. At 622, I'm doomed (there are some FPGA options
at that speed, but none with sufficient pin count that I'm familar with).
 
If people want to have the lowest-emi, longest distance, best noise immunity,
and fewer pins...let them eat cake and use XAUI. The reason for having
two distinct backside interfaces is to support different needs....let's keep
them distinct.
 
Heck, if we're going to change this around so much, I'd vote for 72 pins at
half the speed for each direction. BGA packages provide plenty of pins and
lower clock rates provide just about all the other benefits mentioned for
LVDS (except lower power).
 
RR
----- Original Message -----
Sent: Wednesday, September 20, 2000 5:06 PM
Subject: Re: Proposal: XGMII = XBI+

Curt, who is Roger?  :) My responses to your points are contained below:

>Hi Shawn and Roger,
>I strongly disagree with your preference for LVDS, for following reasons:
>
>- Going to 625 MHz signaling, is pushing todays technology
>  TOO far. Beyond what is possible to design with simple
>  ASIC or FPGA methodology and tools. PHY designer are used to complex clock
>  recovery, training sequences, active deskew, complex SPICE simulations,
>  and other tricks. ASIC, and FPGA designers, are use to Synthesis, STA,with
>  some SPICE work to verify I/O timing. 625MHz would make it WAY
>  to complicated for what is needed, and would require a methodology
>  beyond what most ASIC/FPGA designers have today.

Actually, we are talking about 312.5Mhz data signaling with a 625Mhz clock.  I agree 625Mhz data signalling may be a bit over the top, for some.  Still, at 312.5Mhz data signaling has been done for a number of years is common in telecom systems. 

>- Using a impedance controlled HSTL driver, will not consume much more
>  power then and LVDS. Say you have 6 inch trace, 50 ohm source impedance,
>  1.5V VDDQ. The driver will be on until reflection comes back,
>  with an approximate round trip of 2ns. If you have 50 ohm trace and
>  50% switching, which is random data patteren, driver when on will
>  have 0.75 V drop across it, so power consuption is
>  (0.75^2/50)*(2/3.2 *(50/100)= 3.52 mW/signal.
>  For an interface with 37 drivers this would be 130 mW/interface !

Your suggested implementation addresses lower power and reduced component count over SSTL.  However, your implementation derives it's power savings from not having receive termination thus no static power by requiring source termination, via controlled impedance drivers.  My understanding is most ASIC providers do not have controlled impedance drivers (or if they do, they are not well controlled) forcing all or part of the line termination resistance to be done externally, i.e. adding components.  And if you receive terminate rather than allow reflections, you burn power and add more components. 

Most LVDS drivers are commonly available with integrated line termination because the static power is so small.

>- Again,  if you use a impedance controller HSTL drivers, you need NO
>  external components. No LVDS advantage !

Again, controlled impedance drivers are not common and the one I'm aware likely burns more power than what you calculate above. 

>- Just because HSTL is speced in the standard, doesn't mean you have
>  only one option. If you design your parts to have some flexibility,
>  you can future proof, and support 1.8V, HSTL=1.5 V, and 1.2 V signaling.
>  Driver receivers can easily designed to support some extended voltage
>  range. However I strongly suggest this to be left to
>  the implementors, or standard will be too complex.

I agree a receiver circuit can be made to work over a some range of supplies with control of Vref.  Still, we don't see a single ended high speed I/O that is truly supply independent.  HSTL is a JEDEC spec for 1.5v supplies.  

LVDS is supply independent for a wide range of supply voltages.  When supplies gets too low for LVDS common mode, we can tweak it in the same way you are suggesting for HSTL. 

>- Swithing a few signals on my line card from single ended to differential
>  to lower EMI, when I have around 10,000-20,000 other signals, mostly
>  single ended does not seem basis for switching to differencial signaling.

Don't worry about EMI?  Can I quote you on this? :)
 
>-Curt Berg-
>Extreme Networks


-----Original Message-----
From: Jones, Nevin R (Nevin) [mailto:nrjones@xxxxxxxxxx]
Sent: Wednesday, September 20, 2000 5:20 AM
To: '802.3ae'; 'Rogers, Shawn'
Subject: RE: Proposal: XGMII = XBI+



Shawn:

The issues you raised regarding HSTL vs LVDS are timely and brings to mind
the identical concerns that were wrestled with at the OIF PLL group when we
were working on specifying the System Physical Interface (SPI-4) for OC-192.

We did ultimately specify one SPI-4 interface based upon HSTL (although this
was perceived as more of a legacy path) and another more forward looking
version based upon LVDS.

I would agree with you that the choice here should be for LVDS for all of
the reasons you indicated.

Regards,

-Nevin

> ----------
> From:         Rogers, Shawn[SMTP:s-rogers@xxxxxx]
> Sent:         Tuesday, September 19, 2000 5:55 PM
> To:   '802.3ae'
> Subject:      Proposal:  XGMII  = XBI+
>
> To all, now that we have stepped on the slippery ice of re-engineering the
> XGMII interface, I propose that we not fall on our face in adopting HSTL.
> I propose we use the XBI optional PMA interface adopted in Clause 51 with
> a variant (lets call it XBI+) as the interface between the MAC/RC and the
> XGXS.  Why?  It solves the problems people are having with SSTL and will
> have in the future with HSTL and we already have it specified and widely
> adopted (we don't have to start from scratch.)
>
>   
> The problem with HSTL is it is SSTL in sheep's clothing.  HSTL might be a
> better fit for today's ASIC's but in a few years we'll be seeing RFQ's for
> other interfaces.  If we are going to solve the interface issues of power,
> external components,  emi, and timing, solve I'd prefer to solve it once.
>
>
> The justifiable complaints against SSTL and HSTL include:
> 1) Power hungry, especially if the termination resistors are integrated.
> 2) Lots of external components if the resistors are not integrated.
> 3) Not too scalable to various power supply choices like 2.5V, 1.8V,1.5V.
> 4) Not EMI friendly.
> 5) A true differential clock is preferred by some for timing reasons.
>
> By adopting the proposed XBI+ we adopt Low Voltage Differential Signaling
> which has the following advantages:
> 1) Power efficient - just about a 3 or 4ma drive into a 100 Ohm load.
> 2) Few external components - especially if the 100 Ohm termination is
> integrated.
> 3) power supply agnostic - and an LVDS driver & receiver is available in
> just about any ASIC library and many FPGAs.
> 4) LVDS is true differential and small swing- should be a big advantage
> for EMI.
> 5) Again - the clock as well as data is true differential - should be
> easier to hold timings.
>
> The obvious disadvantage of LVDS (or any differential choice) is:  twice
> as many pins! This can be mitigated by doubling the speed of the
> interface. 
>
> Proposal:  Use a variant of the XBI optional interface called XBI+
>
> XBI+ Proposal:
> Take the XBI optional PMA interface adopted in July
> http://grouper.ieee.org/groups/802/3/ae/public/jul00/robinson_1_0700.pdf
>
> and add 1 bit for control per channel, with interface rate of 625Mbps.  
> Use the current XGMII coding proposal via page 8 of:
> http://grouper.ieee.org/groups/802/3/ae/public/jul00/frazier_1_0700.pdf
> with the following data map:
>
>        frazier_1_0700:  
>              CLK/     CLK\    
> D(0:7)      Byte A   Byte E   
> C0          A ctl    E ctl
> D(8:15)     Byte B   Byte F     
> C1          B ctl    F ctl
> D(16:23)    Byte C   Byte G    
> C2          C ctl    G ctl
> D(24:31)    Byte D   Byte H   
> C3          D ctl    H ctl
> Where CLK is running at 156.25Mhz.
>
>          XBI+ Proposal:
>                    clk/                  clk+1/            clk+2/
> clk+3/
> D(0:3)p/n    Byte A high nibble    Byte A low nibble  Byte E high nibble
> Byte E low nibble
> C0p/n        Byte A control                           Byte E control
> D(4:7)p/n    Byte B high nibble    Byte B low nibble  Byte F high nibble
> Byte F low nibble
> C1p/n        Byte B control                           Byte F control
> D(8:11)p/n   Byte C high nibble    Byte C low nibble  Byte G high nibble
> Byte G low nibble
> C2p/n        Byte D control                           Byte G control
> D(12:15)p/n  Byte D high nibble    Byte D low nibble  Byte H high nibble
> Byte H low nibble
> C3p/n        Byte D control                           Byte H control
> Where clk is running at 625Mhz.
>
> That is, fold the parallel bus over in half but run at twice the rate. 
>
> The XBI+ has a total pins = 42. That is more than the current SSTL or HSTL
> proposal (38: 32data + 4control +1 clock + 1 Vref) , but the line
> termination is much easier (one resistor per pair versus one per pin).
> Actually, this termination is often integrated in most Rx buffer pairs
> where for SSTL or HSTL, many design libraries do not have integrated
> termination.  
>
> The last argument is that one device can be used for both sides of the
> XAUI interface, thus offering economies of scale due to increased volume.
>
>
> In actuality, many of the XGXS devices being designed are already being
> implemented with the option of bypassing the 8b/10b encoders giving the
> parallel busses 10bits per channel plus clock anyway, so the LVDS approach
> compares to 42 pins
>
> on the parallel side of the SERDES anyway in many cases.
>
> This approach is clean, but the speed of the bus is twice as fast. This is
> well within the range of speed for LVDS, and I'm told that even FPGAs are
> currently available that have LVDS I/O on them that can operate at this
> speed.  And - if one wanted to bypass the 8b/10b encoders and bring in
> straight 10 bit data - the pin count does not change.  The five LVDS I/Os
> just bring in 5 bits plus 5 bits on subsequent edges of the clock.
>
> This proposal would allow simplification of both Clause 46 and Clause 51.
>
> We can all go home early. :)
>
> Regards,
> Shawn Rogers
>
>