----- Original Message -----
Sent: Wednesday, September 20, 2000 5:06
Subject: Re: Proposal: XGMII = XBI+
Curt, who is Roger? :) My responses to your points are
>Hi Shawn and Roger,
disagree with your preference for LVDS, for following reasons:
>- Going to 625 MHz
signaling, is pushing todays technology
far. Beyond what is possible to design with simple
> ASIC or FPGA methodology and tools. PHY designer are used to
> recovery, training sequences,
active deskew, complex SPICE simulations,
and other tricks. ASIC, and FPGA designers, are use to Synthesis,
> some SPICE work to verify I/O
timing. 625MHz would make it WAY
complicated for what is needed, and would require a methodology
> beyond what most ASIC/FPGA designers have
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
> with an approximate round trip of
2ns. If you have 50 ohm trace and
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
> 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
> 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 lower EMI, when I have
around 10,000-20,000 other signals, mostly
single ended does not seem basis for switching to differencial
Don't worry about EMI? Can I quote you on this?
Jones, Nevin R (Nevin) [mailto:nrjones@xxxxxxxxxx]
Sent: Wednesday, September 20, 2000 5:20 AM
To: '802.3ae'; 'Rogers, Shawn'
Proposal: XGMII = XBI+
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
working on specifying the System Physical Interface (SPI-4) for OC-192.
We did ultimately specify one SPI-4 interface based upon HSTL
was perceived as more of a legacy path)
and another more forward looking
version based upon
I would agree with you that the choice here should be for LVDS
for all of
the reasons you indicated.
Tuesday, September 19, 2000 5:55
> To: '802.3ae'
> Subject: Proposal: XGMII =
> 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
> 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
interfaces. If we are going to solve the interface issues of
> external components, emi, and
timing, solve I'd prefer to solve it once.
> The justifiable
complaints against SSTL and HSTL include:
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
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
power supply agnostic - and an LVDS driver & receiver is available
> 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
> Proposal: Use a variant of the
XBI optional interface called XBI+
> XBI+ Proposal:
the XBI optional PMA interface adopted in July
> and add 1 bit for
control per channel, with interface rate of 625Mbps.
> Use the current XGMII coding proposal via page 8
> with the following data map:
> D(0:7) Byte A Byte
ctl E ctl
D(8:15) Byte B Byte
ctl F ctl
D(16:23) Byte C Byte G
ctl G ctl
D(24:31) Byte D Byte H
ctl H ctl
> Where CLK is running
D(0:3)p/n Byte A high nibble Byte A low
nibble Byte E high nibble
> Byte E low nibble
Byte E control
> D(4:7)p/n Byte B
high nibble Byte B low nibble Byte F high
> Byte F low nibble
> C1p/n Byte B
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
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
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
(38: 32data + 4control +1 clock + 1 Vref) , but the line
> termination is much easier (one resistor per pair versus one per
> Actually, this termination is often
integrated in most Rx buffer pairs
> where for SSTL
or HSTL, many design libraries do not have integrated
> 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.
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
> 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
proposal would allow simplification of both Clause 46 and Clause 51.
> We can all go home early.
> Shawn Rogers