OOB receiver requirement discussion for the 5/27 PHY call

Alvin Cox alvin.cox at seagate.com
Wed May 26 09:48:38 PDT 2010

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1005260_f.htm">HTML-formatted message</a>

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 04b.)
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

More information about the T10 mailing list