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

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

- 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

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

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