RE: XAUI signal detect
Hi,
I'm sorry- Im probably missing something: If it is not a signal, can you
explain what you ment by:
> >
> > 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.
Thx.,
Boaz
> -----Original Message-----
> From: Kesling, Dawson W [mailto:dawson.w.kesling@xxxxxxxxx]
> Sent: Tuesday, February 27, 2001 11:43 PM
> To: 'stds-802-3-hssg@xxxxxxxx'
> Subject: 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
> >
> >
>