RE: Link Status thoughts
Ben,
Link_status is not complete at the PCS. The XAUI link
is long enough that it is possible that a marginal
device has been attached and lock is not obtained.
We can have the case where an XGXS connects to a
daughter card or transceiver module and that device
is not present. Also, as you point out, a DTE XGXS
can function as a PCS.
For indicating a local fault in the receive direction,
this is pretty simple to cope with. For the sake of
easing the discussion, lets say that the status line
is a local fault line - asserted when there is loss
of signal, loss of lock, or loss of sync. It may be
an inband signal or an out of band signal.
At each sublayer, the local fault out (going up the chain)
should then be the OR of the local fault in (from
the direction toward the MDI) and the internal fault
detection (loss of signal, loss of lock, loss of sync)
of the sublayer.
If the signal is out of band, this is just an OR gate.
If the signal is in band, then if I'm getting valid
signal from below I send it on - if the layer below
has detected a local fault the signal I forward will
indicate the local fault. If I'm not getting valid
signal from below, I send the local fault in band signal.
I would suggest that we either keep local fault out of
band all the way up the chain or we convert it from
out of band to in band at the PCS. My preference would
be the latter though the one concern I have is it uses
more of our fairly limited code space to signal it simply.
I have thought of one way around the code space problem.
Right now in the Muller proposal, RF is signaled on
all 4 lanes. One could send the RF code word on two lanes
with K or R on the other two lanes and reuse the same
code word for LF but put it on the other two lanes or
across all 4 lanes (in case one is worried about lane
mix-ups). This is a small complication of the Muller
proposal since currently the same thing is sent on
all 4 lanes, but perhaps no more difficult to implement
then having two kinds of code and it preserves our
unused code space.
The other question you raise is what do we do when the
receive link is fine but there is a problem on the
transmit side between the MAC and the MDI. For instance
a PHY XGXS can't get sync on the XAUI sighal. I think
that that should also assert local fault toward the MAC.
Identifying the exact nature of the local fault should
be left to the MDIO registers. That still leaves the
question of what that PHY XGXS should transmit. Candidates
arme:
Remote Fault
Local Fault
Idle
yet another signal.
If we send Remote Fault then Remote Fault's meaning becomes
the other end of the line detects a problem. The problem
might be in the receive or transmit side, but something
isn't in lock over there. You have to go over to the remote
node to narrow it down.
If we send Local Fault, then Local Fault becomes more like
Receive fault - there is a problem somewhere between the
transmit of the other MAC and me - and Remote Fault is
a Transmit fault - there is a problem between my MAC transmit
and the other MAC's receive. To figure out if the "Local
Fault" is from the other guy's Phy I have to query my
sublayers via MDIO to see if any of them is out of lock
and generating Local Fault. This seems better to me
but it implies we should change the signal names.
If we send Idle, then it seems a hole in our fault detection.
Why do we bother to publish some faults to the remote node
and leave out others?
A new signal - I really want to keep this simple and our
code space for simple signals is limited so I'd rather
not do this one.
I'll try to get a presentation ready for next week.
Pat
-----Original Message-----
From: Ben Brown [mailto:bbrown@xxxxxxxx]
Sent: Tuesday, October 31, 2000 5:46 PM
To: 802.3ae
Subject: Re: Link Status thoughts
Pat,
Would link_status be complete at the PCS? What if a
XAUI link was used to extend the XGMII? Does this
need any indication of the link from the PCS toward
the MDI? What about the case of a DTE XGXS turned
into a PCS because the PHY XGXS/PCS/PMA is really
only a retimer? Does the DTE XGXS not care about
signal_detect in one case but care about it in the
other?
All these cases show me a pretty confusing picture.
I'm hoping someone can enlighten all of us next
week :)
Ben
pat_thaler@xxxxxxxxxxx wrote:
>
> Ben,
>
> I've looked at your slides. I'm not sure if you intend all
> the signals shown coming out of blocks (especially those on
> slides 8 and 10) to be pins. If so, that is way too many
> pins for link status.
>
> What I propose is one pin from the PMD to the PMA indicating
> whether the link is good (that is, signal detect is okay on
> all inputs) or not. One pin from the PMA to the PCS/WIS
> indicating whether the receive link at the PMA and below
> is okay. That would be an AND of the signal it gets from
> the PMD and the PMA's lock signal. The WIS to PCS interface
> is only defined as a logical interface, so it would have
> a message defined to pass whether the link below was up -
> the AND of the signal it gets from the PMA and its frame
> sync acquired status.
>
> Pat
>
> -----Original Message-----
> From: Ben Brown [mailto:bbrown@xxxxxxxx]
> Sent: Thursday, October 26, 2000 8:44 AM
> To: 802.3ae
> Subject: Link Status thoughts
>
> Hey,
>
> After a discussion some of us had during the editorial
> meeting yesterday, I thought I'd put some of our thoughts
> down on paper. There are still quite a few questions
> buried in these slides. Anyone with comments, please
> feel free to share them. I'd like to have these comments
> before the November meeting so we can put a proposal on
> the table.
>
> Thanks,
> Ben
>
> --
> -----------------------------------------
> Benjamin Brown
> AMCC
> 2 Commerce Park West
> Suite 104
> Bedford NH 03110
> 603-641-9837 - Work
> 603-491-0296 - Cell
> 603-647-2291 - Fax
> 603-798-4115 - Home Office
> bbrown@xxxxxxxx
> -----------------------------------------
--
-----------------------------------------
Benjamin Brown
AMCC
2 Commerce Park West
Suite 104
Bedford NH 03110
603-641-9837 - Work
603-491-0296 - Cell
603-647-2291 - Fax
603-798-4115 - Home Office
bbrown@xxxxxxxx
-----------------------------------------