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

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