SAS2 Speed Negotiation 06-515 switching between patterns

Tim Symons Tim_Symons at pmc-sierra.com
Tue Nov 21 17:21:59 PST 2006


* From the T10 Reflector (t10 at t10.org), posted by:
* Tim Symons <Tim_Symons at pmc-sierra.com>
*
I agree with Steve's interpretation also. The pattern should be considered a
"contiguous set" that does not get abbreviated by any other transitions.
Regards
	Tim.
Tim Symons
Principal Engineer
PMC-Sierra Ltd.
Burnaby
Cell: 778 998 5025
E-mail Tim_Symons at pmc-sierra.com
-----Original Message-----
From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Adrian
Robinson
Sent: Tuesday, November 21, 2006 3:59 PM
To: Stephen FINCH
Cc: 'Day, Brian'; 'T10 Reflector'
Subject: RE: SAS2 Speed Negotiation 06-515 switching between patterns
* 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
*
* 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