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

Re: More about XAUI Signal Detect



Hi  

I had a long conversation with Joel Dedrick (PMCC) on the signal detect
subject and where it came from.  Initially I proposed to use analog SD
for wake on IB and to detect possible crosstalk.  XAUI ports
are not supporting remote wake on and near end module can be woken up 
with MDIO.  The question is how much value does detection of croasstalk 
worth?  Assuming 5% crosstalk on 1600 mV signal you get 80 mV of noise 
and you can still build analog signal detect with high level of 200 mV.  

I would also add forcing every retimer to add end of bad packet to 
data frame is probably more burden than adding signal detect.  But, I 
would not go as far as say signal detect must be mandatory, but
certainly 
very good feature.

Thanks,

Ali
    

"Kesling, Dawson W" wrote:
> 
> Boaz,
> 
> The commenter's original intent was to add an additional interface wire. The
> signal detect text in D2.1 did not add an additional interface wire, but
> required a loss-of-signal detection mechanism on the existing XAUI lanes.
> Due to this apparent misunderstanding, we have reset this issue back to
> D2.0. We will reconsider the original comment that spurred the mistaken
> changes (comment #930 to D2.0) when we gather at the Plenary. Any changes we
> make from the D2.0 state will require 75% affirmative vote by the Task
> Force. I hope this clarifies any remaining confusion.
> 
> -Dawson
> 
> -----Original Message-----
> From: Boaz Shahar [mailto:boazs@mysticom.com]
> Sent: Thursday, March 08, 2001 12:54 AM
> To: 'Tord Haulin'; Kesling, Dawson W
> Cc: Serial PMD reflector (E-mail)
> Subject: More about XAUI Signal Detect
> 
> Dawson,
> I think that the original interpretation that is appearing in Clause 47
> (D2.1) is better for us to adopt (That is, to leave it as is).
> 
> To my understanding (Please correct me if I'm wrong), the original
> interpretation is that the XAUI signal detect is an internal variable that
> is transferred from the PMA to the PCS.
> The problems I see with additional signal(s) are:
> 
> 1.A signal (Either differential or single ended) does not solve all the
> problems. For instance, if you have a disconnected lane between two XAUI
> agents, this lane might get an adjacent lane signal as a result of XTALK or
> mutual inductance, and you will see there logically valid signal, that
> hopefully will have lower amplitude. So, you probably have to detect low
> level signal in the PMA and generate LF anyway. A signal detect signal will
> not have any benefit.
> 
> 2.Addition of signals to the involved ICs make them, and as a result the
> overall system, more expensive
> 
> 3.If the bus is located on a BKPN, you have to transfer the additional
> signals all over the BKPN and connectors, a thing that is not simple to do
> even without it.
> 
> So, as a summary, I think that adding a signal is not a cost effective move.
> 
> Thanks,
> Boaz
> 
> P.S. I understand that now there is a need of 75% to change it, isn't it?
> 
> > -----Original Message-----
> > From: Tord Haulin [mailto:Tord.Haulin@optillion.com]
> > Sent: Wednesday, March 07, 2001 6:36 PM
> > To: Kesling, Dawson W
> > Cc: Serial PMD reflector (E-mail)
> > Subject: RE: XAUI signal detect - D2.0 comment 930
> >
> >
> >
> > Dawson,
> > It seems like the need or benefit of carrying information on loss of
> > signal
> > at another interface across a XAUI link without using error codes
> > already
> > defined is limited to simple retimer applications. How much extra cost
> > for
> > all other XAUI implementations is this saving worth? Agreeing on that
> > might
> > be difficult. Is the receiver at the other end of the XAUI
> > link the only
> >
> > possible entry point for a simple retimer to send its loss of signal
> > info?
> > If not, we might have another alternative not impacting XAUI.
> >
> > This is my interpretation of the alternatives. Please correct or
> > comment:
> > 1. Add message wire(s) to XAUI.
> > 2. Require XAUI transmitters and receivers to communicate LF
> > via muting.
> > 3. Require simple retimers to be less simple and generate error codes.
> > 4. Accept reduced diagnostic capabilities when using simple retimers
> > 5. Find a means for simple retimers to communicate LF without
> > using XAUI
> >
> > Best regards  Tord.
> >
> >
> > -----Original Message-----
> > From: Kesling, Dawson W [mailto:dawson.w.kesling@intel.com]
> > Sent: Tuesday, March 06, 2001 19:03
> > To: Serial PMD reflector (E-mail)
> > Subject: XAUI signal detect - D2.0 comment 930
> >
> >
> >
> > The XAUI signal detect issue needs clarification. Signal detect was
> > added to
> > draft D2.1 of Clause 47 in response to the Task Force resolution of
> > comment
> > #930 against draft D2.0. Upon review, the editors believe
> > there may have
> > been misunderstanding between the commenter's suggested
> > remedy, the Task
> > Force's response, and/or the Editors' implementation of that response.
> > The
> > Task Force Chair has recommended that the resolution of the comment be
> > formally reconsidered at the March meeting to eliminate any and all
> > confusion.
> >
> > Please come to the Plenary meeting next week prepared to discuss XAUI
> > signal
> > detect. We will need to fully discuss and formally decide on this
> > comment
> > before going to Working Group Ballot on the closing day.
> > There have been
> > three proposals discussed on the reflector:
> > 1. Add a new signal detect wire to the XAUI interface. This was the
> > commenter's original intent.
> > 2. Monitor the existing XAUI signals for loss-of-signal. This was the
> > editors' implementation in D2.1.
> > 3. Do not add any new functionality to XGXS/XAUI. Rely on existing
> > in-band
> > LF signaling.
> >
> > Further reflector discussion is appropriate, particularly if
> > there is an
> > proposal I have overlooked or misrepresented. Thank you all for you
> > effort
> > on this and all the XAUI issues.
> >
> > -Dawson Kesling
> >  Editor, Clause 47
> >

-- 
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@broadcom.com
title:Principal Scientist
adr;quoted-printable:;;3151 Zanker Road=0D=0A		;San Jose;Ca;95134;
x-mozilla-cpt:;0
fn:Ali Ghiasi
end:vcard