OOB receiver requirement discussion for the 5/27 PHY call

Elliott, Robert (Server Storage) Elliott at hp.com
Wed May 26 11:53:19 PDT 2010

* From the T10 Reflector (t10 at t10.org), posted by:
* "Elliott, Robert (Server Storage)" <Elliott at hp.com>
That pattern sensitivity problem was observed in some SAS-1 designs, noted as
an editor's note throughout SAS-1.1, and addressed in SAS-1.1 letter ballot
resolution by the May 2005 SAS Physical WG.
The remedy was to recommend that the SP state machine in a PHY_Ready state
ignore alleged OOB signals until loss of dword synchronization occurs.	In
spl-r06c that rule sits in SP15:SAS_PHY_Ready to SP0 and
SP22:SATA_PHY_Ready to SP0:
	This transition may, but should not, occur after:
	a) receiving a COMINIT Detected message before receiving a DWS Lost
message; or
	b) receiving a COMINIT Detected message after sending a Start DWS
	(i.e., the SP state machine should ignore COMINIT Detected messages
unless the SP_DWS state machine has indicated loss of dword synchronization).
If designs are still messing this up, then upgrading that rule to a "shall
ignore" might help.  The basic "signal detect" concept doesn't work with
closed eyes.
Rob Elliott    HP ISS Platform Technology - Server Storage
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Alvin Cox
Sent: Wednesday, 26 May, 2010 11:49 AM
To: t10 at t10.org
Subject: OOB receiver requirement discussion for the 5/27 PHY call
A comment was received concerning the OOB receiver device requirements. In D.
C. mode, since the receiver only uses the idle times as deciding if the OOB
is a valid signal, it is possible that long bursts (i.e., "burst
transmissions" longer than 160 OOBI) are valid detected bursts. If long
transmissions are separated by valid idle times, the receiver state machines
say that these are valid OOB signals. (Reference Table 60 of SAS 2.1 revision
The case is made worse as data speeds increase. The problem has already shown
itself at 6Gbps and will only get worse at 12Gbps. The OOB detector may end
up detecting idle times during long, continuous data transmissions as a
result of the bandwidth of the OOB detection circuitry. These "detected idle
times" may be separated by long times of bursts as the data content produces
a detected value greater than the detection threshold for a period of time
greater than 100 nS, the device burst detection requirement. Even though the
OOB signal receiver device burst time detection requirements table has a
footnote referring to the burst time being transmitted as 160 OOBI, the
receiver requirement has no upper limit on the time which implies that a
burst time longer than the transmitter requirement is a valid burst.
There appears to be a restriction missing in the OOB receiver detection
requirements. Could this be resolved by specifying a limit on how long the
detected burst is allowed to be? I think the reference to the transmitted
signal was an attempt to do this since that restriction was not included in
SAS 1.1, however, this table is dealing with receiver requirements and the
receiver has several restrictions on the signal detection that allow it to
detect signals that would not be compliant with the transmitted signal
Any suggestions on how to "fix" or is this not broken?
Alvin Cox
Seagate Technology, LLC
Cell 405-206-4809
Office 405-392-3738
E-Mail  alvin.cox at seagate.com 
* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at t10.org

More information about the T10 mailing list