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