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

RE: XAUI signal detect




Boaz,
Signal_detect<3:0> are XGXS state variables and are further defined in
48.2.5.1.3. They are not interface (XGMII or XAUI) signals.
-Dawson

-----Original Message-----
From: Boaz Shahar [mailto:boazs@xxxxxxxxxxxx]
Sent: Tuesday, February 27, 2001 3:46 AM
To: 'Kesling, Dawson W'; 'Joel Dedrick'
Cc: 'stds-802-3-hssg@xxxxxxxx'
Subject: RE: XAUI signal detect



Hi,
As an additional XAUI signal-Should'nt it appear in Fig. 47-2 (P. 278)? 
And:
1.It is differential / single ended?
2.Its electrical parameters are identical to those of XAUI Lip/n signals?
Others?
Thx.,
Boaz

> -----Original Message-----
> From: Kesling, Dawson W [mailto:dawson.w.kesling@xxxxxxxxx]
> Sent: Monday, February 26, 2001 10:22 PM
> To: 'Joel Dedrick'
> Cc: 'stds-802-3-hssg@xxxxxxxx'
> Subject: RE: XAUI signal detect
> 
> 
> 
> Joel,
> 
> Here is the background you asked for on this change. Comment 930 was
> accepted in principle at the Interim in Irvine last month, meaning the
> proposed remedy that "we need to add signal detect line to the XGXS
> interface because a PHY end that is a simple retimer is 
> unlikely to want to
> generate LF codes" was accepted. The detailed implementation 
> of the change
> was left to the editors. This detailed editing was worked out 
> at the open
> editors meeting hosted by the 10GEA in San Jose on Jan. 25, where the
> editors and other interested parties participated in detailed 
> preparation of
> D2.1. The text in this case was leveraged from subclause 
> 39.2.3 and altered
> as needed to fit XAUI/XGXS.
> 
> Thank you for the thorough description of your concern. I 
> would like to hear
> from other circuit designers concerning implementation practicality.
> 
> -Dawson
> 
> -----Original Message-----
> From: Joel Dedrick [mailto:Joel_Dedrick@xxxxxxxxxxxxxx]
> Sent: Friday, February 23, 2001 3:33 PM
> To: 'dawson.w.kesling@xxxxxxxxx'
> Cc: 'stds-802-3-hssg@xxxxxxxx'
> Subject: XAUI signal detect
> 
> 
> Dawson:
> 
> In an editor's note on 278, you indicate that signal detect 
> was added to
> XAUI as part of a resolution of comment 930.  Was this left 
> to editorial
> license, or was a specific remedy voted on?  We think this is 
> a bad idea,
> for reasons given below, and will recommend it be reversed.  
> We'll input a
> comment, but I wanted to find out where it originated.
> 
> The note indicates it was a response to comment #930, which 
> presumes the
> existence of a simple retimer in the PMA, which wants to relay a
> loss-of-light input over XGXS (XAUI) without use of a LF 
> code, presumably by
> squelching its output.  Since the XGXS is AC coupled, this 
> will result in
> differential inputs at the DTE end which are biased at their switching
> point.  The addition of a signal detect function I believe is 
> an attempt to
> recognize this condition and ensure that the lack of a valid signal is
> detected at the DCE.
> 
> We think that this new function isn't needed, and that it 
> will have a pretty
> negative impact on XAUI performance and reliability.  It's not needed
> because even simple retimers could easily implement a mode 
> which outputs the
> LF sequence interspersed with idle repeatedly when a signal 
> detect input
> from the optics is inactivated.  It may be acceptable to not 
> randomize idles
> in this fault condition.  This method for communicating LF is
> extraordinarily simple -- there's no reason to define another one.
> Moreover, the basic function of the retimer is to reset the 
> jitter budget.
> Since this is best done with an implementation which fully 
> decouples the
> media clock from the XGXS clock, the proffered case of a 
> simple retimer
> which does not have this capability may be rare.  A full 
> retimer, which
> would include a clock tolerance FIFO capable of IDLE insertion/removal
> clearly could obviously generate LF sequences.  Easing 
> implementation of the
> regenerator-style retimer does not justify bur!
> dening every XGXS implementation with a significant performance and
> reliability penalty.
> 
> The more important objection is that implementing an analog 
> signal detect
> will reduce performance and reliability of all XAUI implementations to
> support a rare case.  Here's why:
> 
> Typical forward crosstalk for 50 Ohm signals implemented with 
> stripline
> construction and 9 mil space is about 5%.  This value 
> saturates in only 2 cm
> of side-by-side run for the risetimes typical of XAUI signals.   5%
> crosstalk with a 800 mV single-ended drive results in 40 mV 
> of single-ended
> noise coupled to the line, from a single interferer and a 
> coupled length of
> 2 cm.  For even modest run lengths, and including other noise 
> effects, a
> minimum of 100mV of effective differential noise would be 
> expected.  This is
> by no means worst case.  
> 
> In theory, signal detect functionalilty could be implemented 
> either as an
> analog envelope detector, or by differentially biasing the 
> inputs and then
> detecting a continuous zero at the input.  But, an envelope 
> detector which
> can reliably detect a signal smaller than the 200mV XAUI 
> sensitivity but
> larger than the 100mV expected noise across process, voltage, and
> temperature is a challenging design, which would 
> significantly complicate
> the already difficult XAUI receiver.  This receiver is required by the
> deterministic jitter and ISI requirements to provide gain to 
> a pulse of less
> than 200 ps. duration and 200 mV differential amplitude.  
> Such a high gain,
> wide bandwidth amplifier will almost certainly oscillate if 
> its inputs are
> biased at zero differential voltage, with undriven, AC 
> coupled inputs.  So,
> if squelched outputs on XAUI lanes are an acceptable way to indicate
> failure, then offset bias must be used to prevent 
> oscillation.  However,
> 100mV of differential offset would di!
> rectly subtract from the sensitivity of the receiver, 
> resulting in a severe
> reduction in reach.  In addition, it would displace received 
> edges in time,
> adding the equivalent of .1 to .2 UI of deterministic jitter. 
>  This seems
> like an unacceptable penalty.
> 
> 
> Best Regards,
> 
> Joel
> 
>