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

RE: XAUI signal detect


"Table 47.1 states that signal-detect should be OK if the input amplitude is
larger than the "actual sensitivity of the specific receiver"."

There is a misunderstanding. The table does not state that the s_d should be
OK if the input amplitude is larger than the actual sensitivity of the
specific receiver. This input situation could fall into either the 2nd or
3rd rows and result in s_d of either OK or Undefined, depending on the
nature of the signal. Only if the input signal is a valid XAUI signal (i.e.,
compliant with must s_d be OK. But if the signal is larger than
receive sensitivity and yet not a valid XAUI signal (such as less than 200
mVpp or in some other way non-compliant with, then the behavior is

"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

Only if the crosstalk results in a valid XAUI signal on the unintended
receiver. If a system implementation allows crosstalk to result in a valid
signal (including amplitude and other characteristics) on an unintended
receiver, I think that there is a serious system design problem.

I'm interested in Rich's and Brent's thoughts on your state machine
suggestion. Thanks, Tord.

-----Original Message-----
From: Tord Haulin [mailto:Tord.Haulin@xxxxxxxxxxxxx]
Sent: Wednesday, February 28, 2001 9:19 AM
To: Kesling, Dawson W; Joel Dedrick
Cc: stds-802-3-hssg@xxxxxxxx
Subject: RE: XAUI signal detect

I agree with some of Joel's concerns on designing a reliable signal
for XAUI.
Table 47.1 states that signal-detect should be OK if the input amplitude
larger than the "actual sensitivity of the specific receiver". Thus it
perfectly OK for a sensitive receiver that is picking up cross talk from
neighbor channel via open lines on the inputs to set signal_detect to
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,
signal detect is used as an additional requirement for acquiring sync on
of three comma detects. In the case of a fiber connection this saves the
engine from hunting for commas in lack of an input signal. In the case
an open XAUI link with cross talk you will probably get either both a
signal_detect and false commas or neither. So then the signal detect
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
from it when all XAUI lanes are open bouncing 100% reflection back on
neighbor channels because of an unplugged board?

Maybe the same objectives for the PCS synchronization can be achieved by
means in the XAUI case. Requiring a specific separation of commas might
stop some false signals from passing the sync algorithm, and it could
the trouble of passing more signals across the interfaces for multi-chip


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


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
generate LF codes" was accepted. The detailed implementation of the
was left to the editors. This detailed editing was worked out at the
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
as needed to fit XAUI/XGXS.

Thank you for the thorough description of your concern. I would like to
from other circuit designers concerning implementation practicality.


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


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
for reasons given below, and will recommend it be reversed.  We'll input
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
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
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
negative impact on XAUI performance and reliability.  It's not needed
because even simple retimers could easily implement a mode which outputs
LF sequence interspersed with idle repeatedly when a signal detect input
from the optics is inactivated.  It may be acceptable to not randomize
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
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
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
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
noise coupled to the line, from a single interferer and a coupled length
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
analog envelope detector, or by differentially biasing the inputs and
detecting a continuous zero at the input.  But, an envelope detector
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
the already difficult XAUI receiver.  This receiver is required by the
deterministic jitter and ISI requirements to provide gain to a pulse of
than 200 ps. duration and 200 mV differential amplitude.  Such a high
wide bandwidth amplifier will almost certainly oscillate if its inputs
biased at zero differential voltage, with undriven, AC coupled inputs.
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
reduction in reach.  In addition, it would displace received edges in
adding the equivalent of .1 to .2 UI of deterministic jitter.  This
like an unacceptable penalty.

Best Regards,