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

RE: XAUI signal detect




Tord,

"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 47.3.4.1) 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 47.3.4.1), then the behavior is
"Unspecified". 

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

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

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



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