[T10] Query on Persistent Connections

Pooja Gupta pooja.gupta at synopsys.com
Tue Dec 18 21:51:12 PST 2018


+T10

From: Tim.Symons at microchip.com [mailto:Tim.Symons at microchip.com]
Sent: Tuesday, December 18, 2018 6:28 AM
To: pooja.gupta at synopsys.com
Subject: RE: Query on Persistent Connections

Pooja,

In your ladder diagram have you omitted EOF from the initiator?

*        I expect it to precede the DONE (NORMAL) from the target, to indicate the transaction is complete.

>From the sequence of events:

1.      the initiator is requesting persistent connections when it sends the OAF with the SEND EXTEND bit set to one.

2.      When the initiator receives the EXTEND CONNECTION (NORMAL) response from the target, then the persistent connection is confirmed and established.

3.      When the initiator receives the DONE (NORMAL) primitive from the Target, then the persistent connection is terminated.

4.      It seems strange that the Initiator is sending an EXTEND CONNECTION (NORMAL) because it has already received a DONE (NORMAL) from the target.

You should investigate further into:

a)      the sequence that causes the target to send a DONE (NORMAL); and

b)     why does the initiator send an EXTEND CONNECTION (NORMAL) after it received DONE (NORMAL)

Regards
Tim.

From: Pooja Gupta <pooja.gupta at synopsys.com<mailto:pooja.gupta at synopsys.com>>
Sent: Thursday, November 29, 2018 11:52 PM
To: Tim Symons - C33374 <Tim.Symons at microchip.com<mailto:Tim.Symons at microchip.com>>
Subject: RE: Query on Persistent Connections

Hi Tim,

Thanks for the quick response. I understand the behavior where DONE is received after persistent connection is established, as that is clearly mentioned in the spec.

The question is about the case where only Target has sent the EXTEND_CONNECTION (NORMAL) and before EXTEND_CONNECTION (NORMAL) is received from Initiator, it transmits a DONE (NORMAL).
                                                         [cid:image001.png at 01D49628.6DCA9C00]
Questions:


1.      Is it acceptable for Target to send DONE (NORMAL) before the complete exchange of EXTEND_CONNECTION (NORMAL) has happened?

2.      Per spec the Initiator remains in EM1 state until it gets an EXTEND_CONNECTION Transmitted message. The initiator is in EM1 state when the DONE primitive is received. The spec does not describe how "DONE Received message" by EM1 is handled. Are we to assume DONE received in the EM1 state shall be ignored?

3.      Target sent EXTEND_CONNECTION (NORMAL), but as Initiator is sending a frame of its own the tx of EXTEND_CONNETION (NORMAL) is deferred.  Meanwhile the Target sends DONE (NORMAL). In such a case should the initiator still send EXTEND_CONNECTION (NORMAL)?
Regards,
Pooja


From: Tim.Symons at microchip.com<mailto:Tim.Symons at microchip.com> [mailto:Tim.Symons at microchip.com]
Sent: Friday, November 30, 2018 4:05 AM
To: pooja.gupta at synopsys.com<mailto:pooja.gupta at synopsys.com>
Subject: RE: Query on Persistent Connections

What is the argument for DONE primitive that the target is sending?
It is valid for a device to send a DONE primitive to close a persistent connection and this will cause a transition from SSP_EM2:Manage to SSP_EM1:Establish, with the message of Persistent Connection (disable).

---------------------------------------------------------------------------------------------
[SPL5r06 Section 4.1.13 Persistent connections] indicates:

4.1.13.1 Persistent connection operation
A persistent connection is an SSP connection (see 4.1.12) that:
a) is established after an EXTEND_CONNECTION (NORMAL) (see 6.2.7.5) has been transmitted and received inside the SSP connection;
b) persists as long as the connected SAS initiator phy and SAS target phy:
A) transmit SSP frames; or
B) periodically exchange EXTEND_CONNECTION (NORMAL)s (see 6.20.9.12);
c) causes the PL_PM state machine to ignore the Bus Inactivity Time Limit timer, the Maximum Connect Time Limit timer (see 7.2.3.4.1), and the MAXIMUM BURST SIZE field (see 9.2.7.2.4); and
d) ends:
A) after a DONE is received;
B) if a Phy Layer Not Ready confirmation from the phy layer occurs during the SSP connection; or
C) if an abort connection occurs (see 6.16.7).

---------------------------------------------------------------------------------------------

[SPL5r06 Section 6.20.9.12.4 SSP_EM2:Manage] indicates:

6.20.9.12.4 SSP_EM2:Manage
This state:
a) requests the SSP transmitter transmit EXTEND_CONNECTION; and
b) monitors the receipt of EXTEND_CONNECTION.
Upon entry into this state, this state shall initialize and start:
a) the Transmit Extend Connection timer; and
b) the Persistent Connection Timeout timer.
If this state receives:
a) a Frame Transmitted message, then this state shall initialize and start the Transmit Extend Connection timer; or
b) a Transmitting Frame message, then this state shall stop the Transmit Extend Connection timer.
If the Transmit Extend Connection timer expires, then this state shall:
1) wait for a Tx Balance Status (Balanced) message;
2) send a Transmit EXTEND_CONNECTION (Normal) message to the SSP transmitter; and
3) after receiving an EXTEND
If this state receives an EXTEND_CONNECTION Received message, then this state shall initialize and start the Persistent Connection Timeout timer.
If this state receives:
a) an SOF Received message, then this state shall stop the Persistent Connection Timeout timer; or
b) an EOF Received message or B_EOF Received message and the Persistent Connection Timeout timer is currently stopped, then this state shall initialize and start the Persistent Connection Timeout timer.
If:
a) the Persistent Connection Timeout timer expires;
b) this state receives a DONE Received message;
c) this state receives a Close Persistent Connection request; or
d) this state receives a DONE Transmit Requested message,
then this state shall send:
a) a Persistent Connection Established (Disabled) confirmation to the port layer; and
b) a Persistent Enable Disable (Disable) message to the SSP_RCM state machine.
If this state receives a No Pending Tx Frames request, then this state shall:
1) wait for a Tx Balance Status (Balanced) message; and
2) send a Transmit EXTEND_CONNECTION (Normal) message to the SSP transmitter.

6.20.9.12.5 Transition SSP_EM2:Manage to SSP_EM1:Establish
This transition shall occur:

a)      after a Persistent Connection Established (Disabled) confirmation is sent to the port layer.

---------------------------------------------------------------------------------------------


From: Pooja Gupta <pooja.gupta at synopsys.com<mailto:pooja.gupta at synopsys.com>>
Sent: Thursday, November 29, 2018 2:09 AM
To: Tim Symons - C33374 <Tim.Symons at microchip.com<mailto:Tim.Symons at microchip.com>>
Subject: Query on Persistent Connections

Hi Tim,

I have a query on persistent connections. I tried sending this query on T10 but somehow this mail is not getting delivered (please see attached)
This is the query:
============================
Is it legal for recipient of OAF with send_extend=1 to send DONE after sending EXTEND_CONNECTION(NORMAL) and before EXTEND_CONNECTION(NORMAL) is received.

We are seeing a situation where EXTEND_CONNECTION(NORMAL) was received from Target, but as Initiator is sending a frame of its own the tx of EXTEND_CONNETION (NORMAL) is deferred.
Meanwhile the Target sends DONE. Please clarify, in such a case should the initiator still send EXTEND_CONNECTION(NORMAL)?
============================
Regards,
Pooja

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.t10.org/pipermail/t10/attachments/20181219/7f2f809b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 28162 bytes
Desc: image001.jpg
URL: <http://www.t10.org/pipermail/t10/attachments/20181219/7f2f809b/attachment.jpg>


More information about the T10 mailing list