RE: MAC/ASIC Interface

["Chang, Edward S" <Edward.Chang@xxxxxxxxxx>]

Dan:

I think we all agree the serial data are differential as they are
implemented in all SERDES devices today.  However, the single-ended signals
are only for the parallel I/O side, either 32 bits-wide or 40 bits-wide with
8B/10B, where the headache of excessive line-count exists. 

The use of TI's 2.5 Gbps SERDES core is also one of the practical approach,
but to series four SERDESs in one, and deserize a serial data into four
independent SREDESs, a deskew buffer is required in each transmitting and
receiving ends.  Although the buffer size can be small, within  a bit or
several.  However, it is not deskew free, even you mentioned that each
SERDES is self-clocking, otherwise, skew will consume the very precious data
recovery margin.        

Nevertheless, we all agree it has to be cost-effective. 

Ed Chang
   

-----Original Message-----
From: Dan Ray [mailto:dray@xxxxxxxxxx]
Sent: Wednesday, June 09, 1999 2:14 PM
To: stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
Subject: MAC/ASIC Interface 




Hello 10G'ers,

    The discussion concerning the MAC/ASIC interface is an
important one, in that as has been mentioned several times,
if this interface in not cost-effective for several 
"generations" of silicon features sizes, we will be faced
with the unappealing prospect of having this interface 
burden future PHYs with unneeded costs.  Furthermore, in the
time it takes to develop this standard, process geometries
and hence the area required for transistors will continue to
shrink at a substantially faster rate than I/O pads, which
are largely constrained by off-chip interface factors (e.g.
load driving and ESD protection).  Given this, I believe we
should strive for an interface that minimizes I/Os, even if
this interface is a bit more complex in terms of logic required
to implement it.  

    One possible solution to this is to consider one of the
most effective high bandwidth interfaces in use today, the 
SERDES interface used for 1.25Gb/s and soon 2.5Gb/s fiber
modules.  This differential interface has proven to be robust
and is used widely as both an inter-chip channel but also 
across backplanes and even through modest lengths of twinax
cable.  Cost effective chips for this interface have been 
available for several years, and there are now several ASIC
vendors with this capability in their libraries today (e.g.
http://www.ti.com/sc/docs/news/1998/98080a.htm).  By the
time PHY implementors realize devices based on this standard 
it will be commonplace for these types of interfaces to be 
readily integratable, as the need to reduce I/Os continues to 
push devices vendors to higher speed interfaces.  

    From a PHY developers standpoint, the SERDES interface is
MUCH more amenable to integration into a device with other 
high-speed mixed-signal circuitry, as the differential nature
of the interface enables implementation with a minimum of signal 
integrity degradations and power supply noise.  It is conceivable
that use of a wide, single-ended, digital interface @ 300Mhz+
may become a limitation on PLL jitter performance.  One possible 
differential SERDES-type approach is to use 4x 2.5Gb/s interfaces,
and use the same bit-level encoding (e.g.4B/5B) on these signals
that we determine is to be used for the 10G line/fiber interface
(with some reduction to allow for signaling).  One potential concern
is that at these speeds, differential trace delays will require that
EACH of the 4 receivers will have to extract it's own timing 
information, and the resulting 4 data streams be aggregated to get
one 10G stream.  This process is now performed in 1000T today
(with 4 250Mb/s receive data streams being combined into one gigabit
stream) and is straight forward.  The good news is that this 
eliminates problems with clock/data skew and set-up/hold times. 

    While the use of a 2.5Gb/s SERDES type interfaces may seem a 
bit much today - as the 100M experience shows - when transistors
get cheaper faster than I/Os, there is great incentive to reduce
the number of these expensive I/Os.  This can lead to non-standard
or "defacto" standard implementations, which do not benefit from
the rigor of a standards review process.  By selecting an interface
that is proven today, is already available in ASIC libraries,
and will likely continue to be used by device vendors as a means
of reducing I/O requirements, we can "future-proof" this portion
of the standard. 

*********************************
Dan Ray
Level One Communications
9750 Goethe Road
Sacramento, CA  95728
(916) 854-2828
dray@xxxxxxxxxx
*********************************