| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
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