RE: Link Status thoughts
Rich,
I agree with much of your message, but there are some points on which
I differ.
From Rich's message: I believe that the logical and of all
conditions from one DTE to the other should be used by the PCS and
eventually reported as Link Status in Status Register bit 1.2.
Pat: This puts the PCS in the position of collecting phy inputs,
but it is neither at the top of the stack nor at the bottom.
The only device that it always at the top of the stack is the
RS and it doesn't have an MDIO/MDC. The string of "christmas tree lights"
should be read from the top which either means that the management
agent needs to be smart enough to check at the DTE XGXS when one
is present or at the PCS if there are no XGXS sublayers present.
This is a reasonable approach. The other alternative is to
read the cummulative link status at the RS as a Clause 30 managed
object.
Secondly, while it would be useful to report the cummulative
link status in a register bit, we should also have a bit
to report the status of the individual sublayer so we don't
make debugging problems as hard as fixing a broken light string.
On what needs to be reported "real time". There are two reasons
to want a real time path to communicate link status between
sublayers.
First, some layers cannot generate idle output signals
when they do not have valid input signals. For instance, a
10GBASE-R based PMD cannot generate an idle because the PCS
scrambles the data. Similarly the WIS cannot generate idle to
the PCS. It has been observed that PMDs without input signal
sometimes pick-up the crosstalk from their transmitted signal
as input. We don't want to be decoding a flaky signal and
risk receiving bogus packets. A signal detect/link status
is one way of protecting agains that. A signal that is passed
up the stack to the PCS sublayer may be enough to protect
against this since PCS and XGXS can produce idle out when
they do not have input sync.
Secondly, to produce Remote Fault in a timely fashion, we
need to have real time knowledge of the link status. Of
course this is only important if we decide to put an RF
mechanism into the standard. How far up the stack this
signal needs to go depends on where we put the RF mechanism.
I agree with Rich that biasing or squelching outputs to
indicate faults are poor methods for the reasons he
suggests. However, I do not agree that PMDs and PMAs
which are simple retimers should put out some kind of
encoded fault signal. It is a common situation for some
ports of a switch to not be connected. We do not
want them generating a signal that creates an EMI problem
so any fault signalling done via the serial interfaces
would imply being able to generate something equivalent
to the idle we have defined for XAUI and the X PCS.
This would be a burdensome amount of circuitry for a simple
retimer or a PMD. With the R PCS encoding and the WIS, this
is even more burdensome. Therefore, I believe that up to the
WIS/PCS, local fault should be signaled with a simple
pin. Pins have costs and we need to limit them, but one
pin is reasonable for this function.
From the PCS on up, we could allocate another one of our
control codes to be used like the RF code is for Local
Fault. This should work fine with Shimon's proposal.
Pat Thaler
-----Original Message-----
From: Rich Taborek [mailto:rtaborek@xxxxxxxxxxxxx]
Sent: Friday, October 27, 2000 9:43 PM
To: HSSG
Subject: Re: Link Status thoughts
My buck three eighty on Link Status Reporting. I apologize in advance,
this is another long-winded note. Please don't attempt to read without
grabbing a long cold one first :-)
Ben has put together a very good list of issues on the subject of link
status reporting. I'd like to add the following issues to this list.
Some of these new issues have been mentioned in subsequent discussion on
this thread.
- What is the transport mechanism for link status reporting? Pins,
Tx_Squelch/Rx_Bias and MDIO have been suggested thus far. An additional
alternative is link encoding similar to that suggested for Remote Fault
and Break Link.
- How do the additional 10G intermediate link status conditions tie
into Link Status, which is historically defined as Status Register bit
1.2 (1=link up, 0=link down)? I view the string of status conditions as
a string of cheap christmas tree lights with any bulb out taking the
down the whole string/link. However, the DTE need only look at SR bit
1.2 to determine whether or not the link is usable.
My answers to Ben's issues in order to frame my vision of 10GE Link
Status Reporting follow:
- What kinds of status are available from all the layers?
Ben answers this in the slides which follow. The signals are all some
form of signal detect or sync. I believe that the logical and of all
conditions from one DTE to the other should be used by the PCS and
eventually reported as Link Status in Status Register bit 1.2.
- What needs to go "up the stack" in real time?
I assume that "up the stack" means to various PHY elements including
PCS's, WIS's, XGXS's, XGMII, RS and eventually Link Status in Status
Register bit 1.2. The conditions that need to go up the stack are the
various forms of signal detect and sync. I'll generalize these
conditions as "intermediate link status". MDIO is not an appropriate
real time transport mechanism. Therefore, the appropriate transport
mechanisms are limited to pins and link encoding of intermediate link
status.
- What needs to be available for debug?
Everything capable of being reported. This includes all forms of
intermediate link status from all link elements.
- Where can that debug information be found?
No real time reporting requirement exists here. In fact most
intermediate link status should be latched. MDIO is an excellent
reporting mechanism for intermediate link status.
On to my thoughts on how Link Status reporting should work:
1) Squelch/Bias as a signal detect transport: This may be a reasonable
mechanism in a simple system such as Gigabit Ethernet where the PMD
consisted of an opto-electronic converter whose system side output
connects to a SerDes chip. The receive side of this SerDes chip performs
the clock and data recovery function. Squelching of the signal at the
output of the Limiting/Post-Amp and bias at the SerDes input may
effectively be used to indicate no signal present at the optical input.
However, this mechanism is inadequate for most embodiments of 10GE which
require the transport of multiple intermediate link status going "up the
stack" from the optical receiver. In many cases illustrated in Ben's
slides, the PMD is not attached directly to the PCS or multiple
essentially independent links exist between the PMD and Reconciliation
sublayer. The biggest problem that this mechanism creates is it's
inadequacy to debug/perform link fault isolation.
In addition, I agree with Ed Grivna in his assertion that the Rx bias
would cause duty cycle distortion of the signal received signal,
resulting in additional jitter at the receiver. This mechanism amounts
to a severe reduction in signal integrity and a poor receive path design
tradeoff.
2) PCS receiver signal detect: This mechanism, suggested by Ed Grivna is
not limited to the PCS, but is generally applicable to all intermediate
elements in a 10G link including the Serial PMA, WWDM retimer, WIS
input, XAUI input, etc. Every electrical interface specified in 10GE is
subject to loss of signal events. For parallel interfaces, this means
that the clock signal is not present. For serial interfaces, since the
clock is embedded in the data, this means that the data stops changing.
Of primary relevance are the 10GE serial electrical links. Those links,
including XAUI, SUPI, retimer-to-PCS, etc. should operate reliably in
the absence of signal on the media for two reasons:
a) They are part of the real-time data path to the PMD,
b) They are critical to facilitate the debug/fault isolation of a link.
I strongly suggest that all 10G serial interfaces be capable of
operating independently in the absence of signal. This means that a WWDM
PMA-to-retimer link should operate independently of what is going on the
media. In other words, separate signal detect logic should be present at
both the Limiting/Post-Amp output connected to the retimer's input as
well as internal to the PMA input. This suggestion emanates from my view
of electrical serial busses being the functional equivalent of parallel
busses and having a BER of 0, not 10E^-12. This methodology allows all
intermediate elements and data paths past the opto-electronics to
operate independently of the PMD and facilitate data/control information
transport and link debug/fault isolation.
Of course, there's no way to outlaw intermediate elements such as simple
retimers which may not have the capability to do more than pass on what
goes in. However, "smart" retimers which are capable of separating,
isolating and transporting link status information from downstream
elements would have a functional advantage over simple retimers. This is
an implementation, not standards issue.
3) Echoing Howard Frazier's sentiments: "Pins = Bad". Based on my
discussion items above, this means that the preferred intermediate link
status transport should be the data/control path itself and not
additional pins. Intermediate link status could be transported directly
through intermediate link elements such as simple retimers.
4) Intermediate link status transport: For real time transport of
intermediate link status conditions, including signal detect from the
media, I propose link encoding similar to that suggested for Remote
Fault and Break Link. I envision the receiver of the link status, such
as the PCS as being able to decode and utilize the intermediate link
status to reliably control the data path with absolutely no compromise
to signal integrity. I have to be a bit vague about the particulars
since Shimon Mueller's proposal is not easily modifiable to transport
additional conditions and LSS is viewed as too complex. If I get some
encouragement to pursue this transport, I will review there the two RF
and BL proposals stand and try to come up with a simple compromise
proposal which also supports intermediate link status transport. Please
write to encourage or discourage me!
5) XGXS bias: This is a really, really bad idea. XGXS receiver bias
significantly decreases receiver sensitivity and decreases jitter
tolerance at the receiver. Higher transmit amplitude may help mitigate
the effects of Rx bias on receiver sensitivity but does nothing to
mitigate the effects of bias on jitter tolerance. In addition, the
higher transmit amplitude is generally directly proportional to the
power consumption of the device. With power consumption of a 10GE PHY
already approximately 20X that of a 1GE PHY given the same technology
(10X speed and 2x SerDes per PHY), power consumption is a critical
factor in the success of the 10GE standard. High speed serial I/O is
hard enough to do without saddling the I/O with circuitry which reduces
Rx sensitivity, decreases jitter tolerance and increases power
consumption.
Let's get back to the original problem and simplify by generalizing: We
need to get signal detect from the PMD to the PCS. There is absolutely
no reason to compromise PHY signal integrity nor increase power (with no
signal integrity benefit) in order to solve the problem. I propose going
with a simple transport mechanism for intermediate link status as
described in (4) above.
--
Best Regards,
Rich
-------------------------------------------------------
Richard Taborek Sr. Phone: 408-845-6102
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Fax: 408-845-6114
2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
Santa Clara, CA 95054 http://www.nSerial.com