Credit Advance Question

Pooja Gupta pooja.gupta at synopsys.com
Thu Nov 13 21:40:44 PST 2014


Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1411135_f.htm">HTML-formatted message</a>
Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1411135_image001.png">image001.png</a>
Attachment #2: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1411135_image002.png">image002.png</a>

Thanks Sanjay for the reply.
1.	 Does that mean Credit would advance only for the Target receiving
OPEN Address Frame, and not for the Initiator sending Open Address frame?
		Is this correct?
2.	 If the above statement in #1 is correct, then why the spec mentions
SL_CC1 -> SLCC3 transition to pass the "Advance Credit" argument which is for
Initiator sending OAF, and which will enable the SSP link layer to increment
its credit as soon as ACCEPT is received.
		 So if one implements sending of "Advance Credit" argument in
SLCC1 -> SLCC3 it will enable the OAF originator also to advance credit.
		Please comment on this.
Regards,
Pooja
From: Sanjay Goyal [mailto:Sanjay.Goyal at pmcs.com]
Sent: Friday, November 14, 2014 11:02 AM
To: Pooja Gupta; t10 at t10.org
Cc: Tim Symons
Subject: RE: Credit Advance Question
Hi Pooja,
As per example below,
1.	 Target sending OPEN_ACCEPT may send RRDY within couple of Dwords
after OPEN_ACCEPT.
2.	 Initiator sending Open Address frame has to receive OPEN_ACCEPT to
know connection is accepted before it can send a frame. So Advance Credit
would not help here.
3.	 Target receiving Open Address frame, if it has a frame to send, it
has to first send OPEN_ACCEPT. Then wait for RRDY before it can send the
Frame to Initiator so "Advance Credit" does help Target in this example.
Hope it helps,
sanjayG
From: owner-t10 at t10.org<mailto:owner-t10 at t10.org> [mailto:owner-t10 at t10.org]
On Behalf Of Pooja Gupta
Sent: Thursday, November 13, 2014 8:26 PM
To: Tim Symons; Pooja Gupta; t10 at t10.org<mailto:t10 at t10.org>
Subject: RE: Credit Advance Question
Tim,
Thanks for your reply. But my question is still unanswered.
The argument defined in SL_CC1 -> SLCC3 will cause the originator to pass the
"Advance Credit" argument. which will enable the SSP link layer to increment
its credit as soon as ACCEPT is received.
So if one implements sending of "Advance Credit" argument in SLCC1 -> SLCC3
it will enable the OAF originator also to advance credit.
Is this correct?
Regards,
Pooja
From: Tim Symons [mailto:Tim.Symons at pmcs.com]
Sent: Friday, November 14, 2014 2:47 AM
To: Pooja Gupta; t10 at t10.org<mailto:t10 at t10.org>
Subject: RE: Credit Advance Question
Pooja,
Thank you for your enquiry about CREDIT ADVANCE in SPL3.
I've attached my original proposal overview as I think this will help to
clarify the operation for you.
Please let me know if you have further questions.
Regards
Regards,
		 Tim
[Description: Description: Description: Description:
cid:image001.png at 01CCB4F4.122C3A10]
Tim Symons
Distinguished Engineer,
Enterprise Storage Division
Desk: (604) 415-6000 Ext. 2864
Cell:	(778) 998-5025
E-mail: Tim.Symons at pmcs.com
--------------------------------------------------------
Overview
This proposal adds the credit advance feature that reduce the time between a
device sending an OPEN address
frame (OAF) and receiving the first data frame from the destination.
If the destination device supports credit advance then the transmitter will
begin send the first data frame
immediately after sending the OPEN _ACCEPT, and if the destination does not
support this field then the
transmitter will wait for the first RRDY to be received and then send the
first data frame.
A CREDIT ADVANCE bit is set to one in the OPEN address frame to indicate that
the phy is ready to receive a data
frame immediately when the destination sends an OPEN_ACCEPT (i.e. the device
should not wait for the first
RRDY before sending the data frame). The first RRDY shall not increment
transmit SSP frame credit when credit
advance is enabled.
Figure 1 shows a ladder diagram of the OAF sequence to the first data frame
comparing phys with and without
credit advance enabled
[cid:image002.png at 01CFFFFB.5134E950]
For legacy systems or when credit advance is not enabled, then in response
to:
1) an OPEN address frame, the destination phy transmits an OPEN_ACCEPT;
2) an OPEN_ACCEPT, the source phy transmits an RRDY when buffer is available;
and
3) an RRDY the destination phy increments the transmit SSP frame credit.
If credit advance is enabled, then in response to:
1) an OPEN address frame with the CREDIT ADVANCE bit set to one, the
destination phy increments the
transmit SSP frame credit and transmits an OPEN_ACCEPT.
From: owner-t10 at t10.org<mailto:owner-t10 at t10.org> [mailto:owner-t10 at t10.org]
On Behalf Of Pooja Gupta
Sent: Wednesday, November 12, 2014 3:00 AM
To: t10 at t10.org<mailto:t10 at t10.org>
Subject: Credit Advance Question
Hi All,
I read the "Credit Advance" feature in the SAS Specification SPL-4 (T10/BSR
INCITS 538 Revision 01, 8 October 2014)
The text added in the Spec for this feature everywhere talks about Credit
being advanced for the end receiving the OPEN Address Frame.
For Example (see the highlighted below),
=========================================================================
3.1.41 credit advance
SSP phy feature that increments a transmit SSP frame credit on receipt of an
OPEN address frame without
waiting for an RRDY
4.1.14 Advancing credit
If an SSP phy that implements credit advance receives an OPEN address frame
with the CREDIT ADVANCE
bit set to one, then the SSP phy:
1) increments the transmit SSP frame credit by one (see 6.18.9.1); and
2) ignores the next RRDY.
A destination SSP phy that does not implement the CREDIT ADVANCE bit (see
6.8.3) does not advance credit.
6.18.4 SSP flow control
If credit advance is implemented (see 4.1.14) and an OPEN address frame with
the CREDIT ADVANCE bit set to
one is received, then:
1) at the beginning of each connection a transmit SSP frame credit of zero is
established;
2) the transmit SSP frame credit is incremented by one (see 6.18.9.4);
3) the first RRDY received does not increment transmit SSP frame credit (see
6.18.9.4); and
4) each subsequent RRDY increments transmit SSP frame credit by one frame.
=========================================================================
But in SL_CC state machine, I could find an instance where it talks about the
end transmitting OAF (see the highlighted below):
=========================================================================
6.16.4.3.4 Transition SL_CC1:ArbSel to SL_CC3:Connected
If credit advance is implemented (see 4.1.14) and:
a) the CREDIT ADVANCE bit is set to one in the transmitted OPEN address
frame; and
b) the SAS PROTOCOL field is set to 001b (i.e., SSP) in the transmitted OPEN
address frame,
then this transition shall include an Advance Credit argument.
=========================================================================
And, this Advance Credit argument is sent to SSP link layer state machines as
Advance Credit
Message
6.16.4.5 SL_CC3:Connected state
if this state is entered with an Advance Credit argument, then this state
shall send an Advance Credit
message to the SSP link layer state machines (see 6.18.9).
6.18.9.4 SSP_TCM (transmit frame credit monitor) state machine
If an Advance Credit message is received, then this state machine shall:
1) increment transmit SSP frame credit by one frame;
2) ignore the first RRDY Received message received; and
3) add one transmit SSP frame credit for each subsequent RRDY Received
message received.
So, from the above snippets, it looks like Credit would get advanced for the
end transmitting OAF as well.
Is this understanding correct?
And, the OAF transmitter would also ignore the first RRDY received, if it
sent OAF with "Credit Advance" set to 1.
Is it correct?
Regards,
Pooja



More information about the T10 mailing list