SAS Phy layer _ some queries

Henry Wong Henry at
Thu Sep 2 11:05:57 PDT 2004

* From the T10 Reflector (t10 at, posted by:
* Henry Wong <Henry at>
Jim Lott wrote:

> * From the T10 Reflector (t10 at, posted by:
> * Jim Lott <Jim.Lott at>
> *
> SAS1.1r5 section 6.5, with regard to oob states:
> "A receiver shall detect an OOB signal after receiving four consecutive idle
> time/burst time pairs (see figure 58). It is not an error to receive more
> than four idle time/burst time pairs. A receiver shall not detect the same
> OOB signal again until it has detected the corresponding negation time
> (i.e., a COMINIT negation time for a COMINIT) or has detected a different
> OOB signal (e.g., if a COMINIT was previously detected, then four sets of
> COMWAKE idle times followed by burst times are detected, a COMWAKE is
> detected; another COMINIT
> may follow)."
> Scenario:
> Let's assume that as many as 100 COMINIT burst idle pairs are received
> without the negation at the end.  The burst idle pairs are changed to an
> invalid OOB or a different OOB signal at some point within the 100 pair.
> COMINIT detected is sent to the SP state machine after 4 consecutive valid
> pairs are received.
> Question:
> What happens after the invalid sequence (or a different OOB signal) is
> received?
> The COMINIT  has been detected and the OOB sequence changes to COMWAKE.
> Does the COMINIT detected remain valid?
> Should COMWAKE detected become valid after detecting 4 COMWAKE sequences?
> Should the COMINIT be considered completed upon detection of the COMWAKES or
> the fact that valid COMINITs are no longer being received?
> Jim
> -----Original Message-----
> From: owner-t10 at [mailto:owner-t10 at] On Behalf Of Elliott,
> Robert (Server Storage)
> Sent: Thursday, August 26, 2004 1:51 PM
> To: t10 at
> Subject: RE: SAS Phy layer _ some queries
> * From the T10 Reflector (t10 at, posted by:
> * "Elliott, Robert (Server Storage)" <elliott at>
> *
> > -----Original Message-----
> > From: owner-t10 at [mailto:owner-t10 at] On Behalf Of Mona
> > Sent: Monday, August 23, 2004 6:44 AM
> > To: t10 at
> > Subject: SAS Phy layer _ some queries
> >
> >
> > * From the T10 Reflector (t10 at, posted by:
> > * Mona <monika.talwar at>
> > *
> > I am studying SAS1.1 specifications.
> >  I have some queries related to the SAS specifications
> >
> >  -- For how much time shall state machine wait for some transmitted
> >   messages from transmitter, for example COMSAS transmitted?
> That is design-specific. The "Transmitted" signals are conceptual signals
> for the purpose of the standard between an independent state machine and an
> independent transmitter.  They might not really exist in hardware.
> >  --Will receiver be able to detect the "completion" of
> > detected OOB signal without detecting negation time(6.5)?
> It's not supposed to.  If the negation time is not present, then it is not a
> completely valid OOB signal.  The "Detected" messages are triggered but not
> the "Completed" messages.
> >  --"Address frames shall not be terminated early". What's
> > meant by early termination??(7.8.1)
> Sending less than 7 dwords before the CRC (i.e. 8 dwords before the EOAF).
> For example, skipping the last dword of an IDENTIFY because it's "reserved"
> is not allowed.
> It's also inadvisable to start sending a BREAK while in the middle of
> sending an address frame.
> >  -- On page 27 (4.1.2) it is stated that SAS phy may use different
> >  roles(initiator or target)  in different connections. On
> > page 119(6.6.5) it
> >  is stated that SAS target phys should not originate a new
> > phy reset sequence
> >  after their first attempt. How is target/initiator device
> > exepected to
> > behave  if its first attemt of phy reset sequence fails?
> If it has initiator things to do (i.e. wants to discover targets to send
> them commands), then it should keep rerunning the phy reset sequence to
> search for something newly attached.
> If it has no initiator things to do (e.g. it is a tape drive with an
> EXTENDED COPY copy manager, which can act as an initiator after being given
> some work to do, but it has no such work pending) then it should follow the
> target advice and let whatever it is attached to discover it first.
> > Mona
> > nSys
> >
> > Solutions for emerging standards
> >
> --
> Rob Elliott, elliott at
> Hewlett-Packard Industry Standard Server Storage Advanced Technology
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at

Hi Jim,
Great question I spent some time musing this one   8-)

My take on this one is if taken 'literally'... "COMINIT Detections"
can be followed with COMSAS/COMWAIT detections w/o a
"COMINIT Completed" (i.e. COMINIT Negation....especially
since I have not seen where "COMINIT Completed" was explicitly
needed anywhere in the SP SMs).   But for COMWAKE or COMSAS,
I feel that their corresponding Negations should be detected
before a different OOB (is validated as Detected).

On the other hand, my implementation (which could change
depending on posting responses you get) is to not validate a different
OOB until the first OOB signal has either been invalidated
..OR.. has it's corresponding Negation requirement met.
==> This was because it seemed that because each OOB signal
transmitted has a specific order & timing, it seems that the
receiver should never receive an out-of-order sequence
of IDLEs/Bursts (especially in a point-to-point physical link).

So, it seems that the only way one would receive some
funny ordering is if:
    (a) provisions in the draft to allow 'Transmission'
         of "partial" OOBs (i.e. COMINITs w/o Negation &/or
         interleaving  of different OOB signals).
or (b) a really bad phy connection (pls no alpha particle jokes).

Guess it's up to the implementor if they want to try to
work with (b) !

Best Regards, Henry

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list