SAS-2: Comment on proposal 90r1: SAS-2 Transmit Identify Three Times

Stephen FINCH steve.finch at st.com
Wed Jun 20 07:29:54 PDT 2007


Formatted message: <A HREF="r0706201_f.htm">HTML-formatted message</A>

I haven't seen an update on this proposal, but I did want to see some
discussion prior to the T10 week, so here goes.
In SAS-2 today a phy sends only one Identify frame and makes one attempt to
receive an Identify.  If the phy receives an SOAF and that address frame is
of the wrong length or has incorrect CRC, the reception attempt fails and
the exchange of the Identify frame fails.  The phy does not go into normal
operation and a phy reset sequence is the only option for recovery. 
The goal, as I understand it, is to allow (not require) a phy to send its
Identify frame three times and to allow it to discard invalid frames and not
treat the detection of an invalid frame as a fatal error.  The reception
process would time out if no Identify frame was received before the Receive
Identify Timeout timer times out.
The issues, as I see them are:
1.  There is no timing specified as to the repetition of Identify frames.  
The Identify frames could be sent back-to-back, with no intervening idle
dwords, or they could be spaced far apart, up to something just short of the
Receive Identify Timeout period.  
It appears there are implementations that are not capable of receiving
back-to-back frames with no intervening idle dwords.  If a phy with such a
receiver were connected to a phy that transmitted the Identify three times
in a row without intervening idle dwords, then the goal of this proposal
would not be obtained.
I see no advantage to sending the multiple Identifies with "significant"
time delay between them.
I would propose that, if a phy transmits three Identifies that a minimum of
six idle dwords be transmitted between the Identify frames and no more that
16 idle dwords be transmitted between Identify frames.	(If these numbers
aren't agreeable, let's find numbers that are.)
2.  If one side transmits the Identify three times and the other side only
once, then the side that send only one will enable its higher layer protocol
state machines after sending only one.	It is possible (and I can argue
probable if the phy reset sequence occurred as a link recovery event) that
the phy sending only one Identify could send an Open Address frame before
the phy sending three Identify frames has entered normal operation.  This
would result in a timeout of an Open request.  Not an unrecoverable event,
but still not a desirable event either.  So, should we require all phys to
not send an Open Address frame until some time frame after the successful
exchange of an Identify?  Like 1 ms?
One last question, should all SAS-2 compliant devices be required to send
three Identify frames?
Additional note:  The text and state changes to the IR state machines (3 of
them), as they appear in the latest proposal, are not sufficient.  If we can
agree to the above issues, then we can work on these issues.
Regards,
Steve Finch
STMicroelectronics



More information about the T10 mailing list