Question: OOB - SAS vs STP/SATA detection

Henry Wong Henry at scs.agilent.com
Wed Jun 16 15:27:29 PDT 2004


* From the T10 Reflector (t10 at t10.org), posted by:
* Henry Wong <Henry at scs.agilent.com>
*
"Shah, Amit M" wrote:

> Henry,
>
> As far as I understand the specs, the SAS spec (rev 5) has defined in
> Table-37 the min. BURST time specification. The table clearly mentions
> that a BURST "should be detected" if the burst time is more than 100
> nsec. Also it mentions that burst "may be detected" if the burst time is
> less than 100nsec. So in your case you could assume that burst could be
> detected even if burst time is less than 100 nsec i.e any transition of
> "any amount of time" could get detected as BURST.
>
> Also the specs mentions "The signals are differentiated by the length of
> idle time between the burst times" -- section 6.5
>
> That is, the OOB signal detection logic really cares about the IDLE time
> between the burst time. The IDLE time is time bound for each OOB signal
> as mentioned in Table 40 (a min. and a max. value has been defined). As
> far as the IDLE time is in the specified range and there is a valid
> BURST (any transition, could be of any duration), the hardware should be
> able to detect the OOB signaling (after "4" IDLE / BURST pairs).
>
> So I believe that the OOB detector logic for SAS, SATA and
> STP/<native>SATA-SATAII compliant type devices would be the same.
>
> Amit Shah
> Sr. Design Engr
>
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Henry
> Wong
> Sent: Tuesday, June 15, 2004 10:16 AM
> To: t10 at t10.org
> Subject: Question: OOB - SAS vs STP/SATA detection
>
> * 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

Hi Amit,

C_O_O_L.......... I guess you meant (Table-39 in SASr5  ..OR..
Table-40 in the current SAS-1.1r4).  Looking at them I now see
your point;  also, noticed the sentence just before table saying:

    "The burst time is not used to distinguish between signals."

Based on what you've pointed out, the table does basically indicate
--> "any amount of time".   I focused too much on the paragraph
after Table-42 where the infamous receiver "SHALLs" appear.

Thanks again!
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