SAS2 Speed Negotiation 06-515 switching between patterns

Adrian Robinson arobinso at vitesse.com
Tue Nov 21 15:58:43 PST 2006


* From the T10 Reflector (t10 at t10.org), posted by:
* Adrian Robinson <arobinso at vitesse.com>
*
I would have to support Steve's interpretation.  That way,
anyone who's training algorithm wants to take advantage of
a known pattern, won't get messed up by the switch.  It's
probably not a problem, but who knows.
Adrian Robinson
Vitesse Semiconductor
On Tue, 2006-11-21 at 13:32, Stephen FINCH wrote:
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Stephen FINCH <steve.finch at st.com>
> *
> 
> Brian,
> 
> 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
> STMicroelectronics
> 303 381-3587
> 
> -----Original Message-----
> From: Day, Brian [mailto:Brian.Day at lsi.com] 
> 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
> algorithm?
> 
> 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 t10.org [mailto:owner-t10 at t10.org] On Behalf Of Stephen
> FINCH
> Sent: Friday, November 17, 2006 8:54 AM
> To: T10 Reflector
> Subject: SAS2: Speed Negotiation proposal 06-515r0 (formerly 06-423r9) now
> available
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Stephen FINCH <steve.finch at st.com>
> *
> 
> 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.
> 
> NO TECHNICAL CHANGES WERE MADE.
> 
> 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.
> 
> Regards,
> 
> Steve Finch
> STMicroelectronics
> 303 381-3587
> Steve.finch at st.com
> 
> 
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
> 
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
-- 
Adrian Robinson <arobinso at vitesse.com>
Vitesse Semiconductor Corporation
*
* 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