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
>
>