RE: XAUI signal detect
All:
There appears to be massive confusion here. Don't know if this will add to it or clear it up, but here goes...
Pat reiterated in her post in this thread, and the language of comment 930 to D2.0 confirms, that what was originally requested was a group of signal detect *wires*, to be added to XGXS. And I remind everyone that the functionality was not intended to detect that the XGXS itself was disconnected. Rather, it was to communicate from a retimer across the XGXS that an optical signal was not being received.
The comment resolution includes this text: "the editors decided to add squelch text following the precidence of clause 39...". The text of 2.1 is unequivocal that a signal-squelch with analog amplitude detect is required, viz: "an unavoidable consequence of the requirements for the setting of the signal_detect<3:0> parameters, implementations must provide adequate margin between the input signal level at which the signal_detect<3:0> parameters are set to OK, and the inherent sensitivity of the XAUI receiver to various noise sources..." This is in concert with Dawson's post in this thread, which indicates that his intention was that signal detect be a state variable, and not a physical wire.
Upon further consideration (see my original post and Tord's followups) it seems there's agreement that XAUI signal detect by means of squelching the signal and detecting this at the receiver is funcamentally flawed. The conversation has thus turned back to implementing signal detect *wires*, where it originally started.
While a group of sideband signals to communicate link status per lane will at least work, I still find it to be unnecessary. We have a perfectly good, reasonably simple way to signal, in band, whether the link is broken or not. We have a prescribed method for finding out which lanes are up or down, and where the signal flow stops. After further thought, I agree with Pat's comment that idles should be randomized all the time, and that having different EMI spectra during fault conditions than otherwise is not good and is easily avoidable. But creating another bundle of four wires just to report whether there's any information on the first bundle of four signals seems excessive to me. If we were willing to double the XAUI pin count, we could have cut the data rate in half, and the implementation would have been a lot easier!
The right solution here is that a XAUI retimer should behave like a good PCS, and signal detect from the PMA should be OR'ed in with the other conditions that cause it to report a Local Fault condition in the usual way, i.e. with LF messages interspersed in the normal (randomized) idle stream.
Regards,
Joel Dedrick
> -----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
>
>