RE: XAUI signal detect
I agree with some of Joel's concerns on designing a reliable signal
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
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
From: Kesling, Dawson W [mailto:dawson.w.kesling@xxxxxxxxx]
Sent: Monday, February 26, 2001 21:22
To: 'Joel Dedrick'
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
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.
From: Joel Dedrick [mailto:Joel_Dedrick@xxxxxxxxxxxxxx]
Sent: Friday, February 23, 2001 3:33 PM
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,
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
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
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.
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.