RE: More about XAUI Signal Detect
I would like to remind everyone that there is a general strategy we have
adopted in 10GbE that if a transmitter (any kind of transmitter, either on
the receive or transmit path) knows that the data it is about to send is
bad, that this fact should be communicated to the next layer for forwarding
all the way to the RS (MAC) at the end of its path.
I realize that "Signal Detect" has a variety of definitions and some of
these definitions claim that "Signal Detect" is not required.
But, let us make sure in our communications that the elimination or
suggested elimination of "Signal Detect" does not carry with it the
elimination of data qualification. We may choose to require all XGXS layers
to use RF/LF. We may choose to require use of "Signal Detect." Just so that
whatever we choose does the entire job.
jonathan
-----Original Message-----
From: Ali Ghiasi [mailto:aghiasi@xxxxxxxxxxxx]
Sent: Friday, March 09, 2001 1:21 PM
To: Kesling, Dawson W
Cc: Serial PMD reflector (E-mail); Ali Ghiasi
Subject: 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@xxxxxxxxxxxx]
> 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@xxxxxxxxxxxxx]
> > 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@xxxxxxxxx]
> > 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.