Credit Advance Question
pooja.gupta at synopsys.com
Thu Nov 13 20:26:18 PST 2014
Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1411133_f.htm">HTML-formatted message</a>
Attachment #1: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1411133_image001.png">image001.png</a>
Attachment #2: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1411133_image004.png">image004.png</a>
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?
From: Tim Symons [mailto:Tim.Symons at pmcs.com]
Sent: Friday, November 14, 2014 2:47 AM
To: Pooja Gupta; t10 at t10.org
Subject: RE: Credit Advance Question
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.
[Description: Description: Description: Description:
cid:image001.png at 01CCB4F4.122C3A10]
Enterprise Storage Division
Desk: (604) 415-6000 Ext. 2864
Cell: (778) 998-5025
E-mail: Tim.Symons at pmcs.com
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:image004.png at 01CFFFF1.3BDCC8C0]
For legacy systems or when credit advance is not enabled, then in response
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;
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
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 220.127.116.11); 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
2) the transmit SSP frame credit is incremented by one (see 18.104.22.168);
3) the first RRDY received does not increment transmit SSP frame credit (see
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):
22.214.171.124.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
b) the SAS PROTOCOL field is set to 001b (i.e., SSP) in the transmitted OPEN
then this transition shall include an Advance Credit argument.
And, this Advance Credit argument is sent to SSP link layer state machines as
126.96.36.199 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).
188.8.131.52 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
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?
More information about the T10