Question: OOB - SAS vs STP/SATA detection

Henry Wong Henry at scs.agilent.com
Tue Jun 15 10:16:27 PDT 2004


* From the T10 Reflector (t10 at t10.org), posted by:
* Henry Wong <Henry at scs.agilent.com>
*
> Draft Scenarios:
>     A) SAS Rev5 (sec 6.5) draft is more stringent than SATA & SATA-II in
>        terms of detection of OOB signaling. SAS draft documents
>        describe detection rqmts of Burst, Idle, & Negation timings.
>        Also indicated is the need that the "...receiver shall
>        detect an OOB signal after....      .....consecutive idle
>        time/burst time pairs...."
>       --> This theme is consistant thru-out the SAS (current/previous) docs.
>     B) The current T13 ATA/ATAPI 7 - Vol3 (sec 14.5.6) draft on SATA describes
>        that  "...OOB signals shall be observed by detection of temporal
>        spacing between adjacent bursts of activity..."  "It is not required
>        for a receiver to check the duration of an OOB burst."
>       --> This theme is consistant within the ATA/ATAPI7 (current/previous) docs.
>     C) The SerialATA Rev 1.0a (6.7.4) draft has "...OOB signals shall be observed
>        by detection of temporal spacing between adjacent bursts of
>        activity..."
>       --> This draft omits the second sentence that exists in the T13 version
>        about "...not required...  ...to check the duration of an OOB burst."
>        I was unable to find any post Rev 1.0a draft documents that further
>        elaborated on OOB signal detection.
>
> It appears that there are two types of OOB detection rqmts based on a devices
> protocol support. Device can support protocol(s):
>       1) SAS only (receiver detection based on Burst, Idle, & Negation timings
>          of idle/burst pairs...see A above).
>   and/or
>       2) STP/<native>SATA-SATAII compliant type devices (receiver detects spacial
>          bursts and depending on draft <T13 vs SerialATA> may ignore burst duration)

> QUESTION <need for clarification/verification>:

> >>> Is the resultant of these 3 draft docs indicating that devices
>     that support more than SAS only (i.e. SAS+STP, SAS+SATA, SAS+SATAII,
>     SAS+STP+SATAII, & etc, & etc....) will need to implement two types
>     of receiver OOB detection designs ??   For example, on power-up during
>     transmit voltage level adjustments <see SAS-r5, section 5.3.4> a device
>     that supports attaching to SAS+STP, will detect DC Idles (a.k.a
>     temporal spacing) ignoring burst duration length while transmitting
>     at SATA transmit levels and if necessary switches to SAS transmit levels
>     and then looks for OOBs with idle/burst time pairs that meet the rqmts
>     described in Table 40, 41, & 42 <see SAS-r5, section 6.5>.
>
> >>> So, bottomline... is it true that all but SAS Only devices will need
>     some sort of "dual mode OOB detection scheme" to meet the current
>     draft/standard docs presently available ???
>
> We're probably all aware of the various hows/whys (e.g. clock tolerance
> differences, DC Idle generation/detection, & etc.).... but the big
> question is how well interoperability is between SAS & STP/SATA (native
> derivatives).
>
> ====> I apologize for the long note... I tried to keep it short.  Any
>            comment/clearification would be of great interest... for example:
>               a) continue & design for dual OOB detection (based on SAS ..vs..
>                   STP/SATA protocol modes)
>               b) change/re-align the drafts to better co-exist
>               c) clearify my misconceptions from the 3 different drafts mentioned
>                   above
>               d) ideas/comments  ??????
>
> Thanks!
> Best Regards, Henry
>
>
>

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