Question: OOB - SAS vs STP/SATA detection
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
> --> 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).
> 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
> ====> 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
> d) ideas/comments ??????
> 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