Re: XAUI signal detect
Hi Farzin
The sginal detect is for XAUI.
Thanks,
Ali
Farzin Firoozmand wrote:
>
> Is the signal detect a XAUI or XGMII signal?
>
> Farzin
>
> -----Original Message-----
> From: Ali Ghiasi [mailto:aghiasi@xxxxxxxxxxxx]
> Sent: Tuesday, February 27, 2001 8:32 AM
> To: Boaz Shahar
> Cc: 'Kesling, Dawson W'; Joel Dedrick; 'stds-802-3-hssg@xxxxxxxx'
> Subject: Re: XAUI signal detect
>
> Hi
>
> In my opinion all control signals should have the same interface as
> XGMII and MDIO. Assuming XGMII and MDIO electrical interface is
> HSTL, then signal detect should be HSTL as well.
>
> Thanks,
>
> Ali
>
> Boaz Shahar wrote:
> >
> > 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
> > >
> > >
>
> --
> Ali Ghiasi
> Broadcom Corp.
--
Ali Ghiasi
Broadcom Corp.
begin:vcard
n:Ghiasi;Ali
tel;cell:(949)290-8103
tel;fax:(408)501-8408
tel;work:(408)922-7423
x-mozilla-html:FALSE
org:Broadcom;Optical Transport
version:2.1
email;internet:aghiasi@xxxxxxxxxxxx
title:Principal Scientist
adr;quoted-printable:;;3151 Zanker Road=0D=0A ;San Jose;Ca;95134;
x-mozilla-cpt:;0
fn:Ali Ghiasi
end:vcard