RE: MAC/ASIC Interface

[Dan Ray <dray@xxxxxxxxxx>]

Ed, 
   
   You raise good points, which I have tried to address below:
> 
> 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. 
> 
I agree the parallel I/O signals are intended for the MAC side of the
PHY, but since they are to be located on the same die as the 10G side
of the PHY, thier impact on performance must be considered.  On the
receive side the PHY would have to drive 32 bits of data at a time,
presumably with a sub-3ns edge rate.  Chip designers do have solutions
for this today, but they are expensive and hard to integrate with a
jitter-sensitive PLL and other mixed signal circuitry (which is why the
current SERDES devices I am familiar with use a low-swing differential
data interface today).  At 10G, with it's likely tighter jitter 
and receive requirements, the problem of isolation of the substantial 
pad-related noise gets significantly worse than at 1.25Gb/s.  
>
> 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.        
>
The deskew buffer is required on both receiving ends, as it is there 
where you have to combine the 4 2.5Gb/s streams into one 10G stream.  
As you suggest, this buffer can be shallow, but it's depth does impose a 
limit on differential skew between the trace lengths.  I would guess that
if a buffer size of 4 bauds is used, we can cover almost any practical 
trace difference delays, and only impose a latency penality of about 1.6ns.
It should be noted that since each receiver is recovering it's own clock,
data/clock skew and it's associated problems are completely removed.  The
board layout constraints are limited to matching 4 pairs of two differential
traces, rather than closely matching 32 data lines and a clock.
> 
> Nevertheless, we all agree it has to be cost-effective. 
> 
It is in that vein that I mention that the die area for the deskew 
function discussed above should be less than the area consumed by 4 
standard ASIC high-drive digital I/O pads at 0.25u, and less than 2
I/O pads at 0.18u, making this an attractive option from a die area
(cost) point of view.  
>
> 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
> *********************************      
>