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

RE: XAUI signal detect

Does this mean we need to squelch the receiver?  


-----Original Message-----
From: Ali Ghiasi [mailto:aghiasi@xxxxxxxxxxxxx]
Sent: Wednesday, February 28, 2001 10:24 AM
To: Tord Haulin
Cc: Kesling, Dawson W; Joel Dedrick; stds-802-3-hssg@xxxxxxxx
Subject: Re: XAUI signal detect


As part of signal detect definition we also need to define off state.
In the IB we have used 85 mV to indicate absent of sufficient signal.
After the signal reaches the sensitivity level (200mV) the SD is
AS Tord mentions the greatest use of SD is for lack of signal or
discriminating against crosstalk or noise.


Tord Haulin wrote:
> Dawson,
> I agree with some of Joel's concerns on designing a reliable signal
> detector
> for XAUI.
> Table 47.1 states that signal-detect should be OK if the input amplitude
> is
> larger than the "actual sensitivity of the specific receiver". Thus it
> is
> perfectly OK for a sensitive receiver that is picking up cross talk from
> a
> neighbor channel via open lines on the inputs to set signal_detect to
> OK,
> since the cross talk has an amplitude larger than its sensitivity!
> Is that the intention?
> If you take a look at the PCS synchronization state diagram Figure 48.8,
> the
> signal detect is used as an additional requirement for acquiring sync on
> top
> of three comma detects. In the case of a fiber connection this saves the
> sync
> engine from hunting for commas in lack of an input signal. In the case
> with
> an open XAUI link with cross talk you will probably get either both a
> false
> signal_detect and false commas or neither. So then the signal detect
> doesn't
> help much.
> The likelihood of an open XAUI is probably not the same as that of an
> unconnected fiber, so maybe the handling could be different. What is
> required
> from it when all XAUI lanes are open bouncing 100% reflection back on
> the
> neighbor channels because of an unplugged board?
> Maybe the same objectives for the PCS synchronization can be achieved by
> other
> means in the XAUI case. Requiring a specific separation of commas might
> stop some false signals from passing the sync algorithm, and it could
> save
> the trouble of passing more signals across the interfaces for multi-chip
> implementations.
> /Tord
> -----Original Message-----
> From: Kesling, Dawson W [mailto:dawson.w.kesling@xxxxxxxxx]
> Sent: Monday, February 26, 2001 21:22
> 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

Ali Ghiasi
Broadcom Corp.