SAS2 Speed Negotiation 06-515 switching between patterns

Stephen FINCH steve.finch at
Tue Nov 21 12:32:57 PST 2006

* From the T10 Reflector (t10 at, posted by:
* Stephen FINCH <steve.finch at>
You've made a good point.  It isn't clear.  But I do have an interpretation
that may apply.
My interpretation is that the SP state machine sends a Transmit TRAIN_DONE
pattern message to the SP transmitter, the SP transmitter does the
transmission and generates a TRAIN_DONE Pattern Transmitted when it has
completed the transmission.  It doesn't honor any other transmission
requests until the one it is working on is completed.
The same sequence is true of the Transmit TRAIN pattern, except that the
TRAIN Pattern Transmitted is not received/used within the SP state machine.
Logically, the TRAIN Pattern Transmitted occurs even if it doesn't cause a
message to be sent.
This is implied in other state machines.  A case in point is state
SL_CC4:DisconnectWait state.  Upon entry, it sends a Transmit CLOSE (Normal)
message or Transmit CLOSE (Clear Affiliation) message to the SL transmitter.
Transition SL_CC4:DisconnectWait to SL_CC0:Idle is described as:
"This transition shall occur after:
a) sending a Transmit CLOSE message to the SL transmitter;
b) receiving a CLOSE Received message; and
c) sending a Connection Closed (Normal) confirmation to the port layer."
Note that it doesn't wait for a CLOSE Transmitted message from the SL
transmitter.  The CLOSE is a triple, so the receiving of a CLOSE Received
message could occur before the transmitter has completed send the requested
CLOSE.	We know that the outgoing CLOSE must be sent in its entirety or else
we would be getting CLOSE timeouts frequently. 
I have always interpreted these sequences in the state machines such that,
once a transmitter starts working on a Transmit xxxx message, it completes
that transmission BEFORE it starts on any new transmission.
If this interpretation is right, then the transmitter, in response to a
request to Transmit TRAIN pattern or Transmit TRAIN_DONE pattern, would
always send a complete pattern before honoring a new Transmit xxxxx message.
So, the transition from SP29:SAS_Train state to SP30:SAS_TrainingDone state
can occur in the middle of the transmission of a TRAIN pattern, but the
transmitter would complete the transmission of the TRAIN pattern that it
started in response to the Transmit TRAIN pattern request of SP29, and then
look at the Transmit TRAIN_DONE pattern from SP30 and do that next.
Again, this is my interpretation.  
Are there any other comments???  Agreements??? Disagreements???
Steve Finch
303 381-3587
-----Original Message-----
From: Day, Brian [mailto:Brian.Day at] 
Sent: Tuesday, November 21, 2006 12:22 PM
To: Stephen FINCH; T10 Reflector
Subject: SAS2 Speed Negotiation 06-515 switching between patterns
So as I interpret this (which is the point of my question), it would be okay
to truncate the both the TRAIN pattern and TRAIN_DONE when switching to a
new pattern due to the state machine changing at arbitrary points in time.
For example, if SP state is currently in SP29:SAS_Train state and
transmitting the TRAIN pattern, when the conditions to transition to
SP30:SAS_TrainingDone occur at an arbitrary point in time, the SP
transmitter would then switch to sending TRAIN_DONE patterns.  
In other words, there may be less than 58 dwords of random scrambled data
between the TRAIN and TRAIN_DONE primitive sequences.
Actually, there might not be anything preventing the TRAIN primitive itself
|from being less than 6 dwords when making this transition... I'm not sure on
this one to be honest.
Same reasoning applies when going from the TrainingDone to PHY_Ready state.
Is there objection to this type of allowed behavior?  Would that behavior be
okay for the receiver that is still training without messing up the training
I feel this should be allowed behavior from a digital state machine design
standpoint, as it keeps it simple... the actual implementation of the SP
state machine does need to know about the specific dword "state"
of the training pattern.  
Brian Day
LSI Logic
-----Original Message-----
From: owner-t10 at [mailto:owner-t10 at] On Behalf Of Stephen
Sent: Friday, November 17, 2006 8:54 AM
To: T10 Reflector
Subject: SAS2: Speed Negotiation proposal 06-515r0 (formerly 06-423r9) now
* From the T10 Reflector (t10 at, posted by:
* Stephen FINCH <steve.finch at>
Following the review during the SAS2 Phy conference call yesterday,
editorial updates have been made to 06-324.  We ran out of revision numbers,
so a new document number has been generated.
It is my belief that we now have the SAS2 speed negotiation process well
defined.  I plan to move to include this information into the SAS2 draft at
the January meetings, so take the time now to review this material.
Steve Finch
303 381-3587
Steve.finch at
* 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

More information about the T10 mailing list