[T10] Request for clarification on CREDIT_BLOCK received message condition for SSP transmitter
lana at cadence.com
Tue Oct 16 15:55:35 PDT 2018
Specification reference : SPL-5r06
220.127.116.11 SSP_TCM (transmit frame credit monitor) state machine
* The CREDIT_BLOCKED Received message indicates that transmit SSP frame credit is blocked. After receiving a CREDIT_BLOCKED Received message, this state machine may ignore additional RRDY Received messages until it receives a Request Close message or a Request Break message.
* This state machine shall handle an EXTEND_CONNECTION Received (Close) message as if a CREDIT_BLOCKED Received message was received.
* The RRDY Received (Close) message indicates:
* that transmit SSP frame credit is available; and
* this state machine shall handle that RRDY Received (Close) message as if a CREDIT_BLOCKED Received message was received.
* If this state receives an RRDY Received (Close) message or an EXTEND_CONNECTION Received (Close) message, then this state shall repeatedly send a Begin Close message to the SSP_TF1:Connected_Idle state.
Question 1: It seems that indirectly, all three conditions 1) CREDIT_BLOCKED Received, 2) EXTEND_CLOSE_CONNECTION received and 3) RRDY_CLOSE are received handled same way.
Considering that, how does the SSP transmitter differentiate between RRDY_CLOSE received condition and CREDIT_BLOCK received condition in terms of sending response?
* While transmit SSP frame credit is not available and transmit SSP frame credit is not blocked, this state machine shall repeatedly send the Tx Credit Status (Not Available) message to the SSP_TF2:Tx_Wait state.
* While transmit SSP frame credit is not available and transmit SSP frame credit is blocked, this state machine shall repeatedly send the Tx Credit Status (Blocked) message to the SSP_TF2:Tx_Wait state.
Question 2: What if transmit SSP frame credit is available (refer below example/scenario) and CREDIT_BLOCK received primitive is received ? In this case, should it send Tx Credit Status (Blocked) or Tx Credit Status (Available) to SSP_TF2 state ?
6.20.8 Closing an SSP connection
If the transmitter has no more SSP frames to transmit and receives a CREDIT_BLOCKED, then it may transmit either DONE (NORMAL) or DONE (CREDIT TIMEOUT).
Question 3: How do we differentiate CREDIT_BLOCKED received condition response with DONE_NORMAL or DONE_CREDIT_TIMEOUT ?
Shall it be interpreted as below ?
1. If transmitter has received CREDIT_BLOCK and it has some (> zero) transmit CREDITs available to transfer, but no pending frames to be transmitted then transmitter will respond with DONE_NORMAL
2. If transmitter has received CREDIT_BLOCK and it has NO TRANSMIT CREDIT available to transfer, but have/have-not pending frames to be transmitted then transmitter will respond with DONE_CREDIT_TIMEOUT
1. Initiator has opened the connection with target, and after accepting the connection Target send 6 RRDY to Initiator
2. Initiator has 4 SSP frames to transmit in this connection
3. While sending 3rd SSP frame, Initiator received CREDIT_BLOCK primitive from Target (due to Rx Credit Control (Blocked) condition at target)
* What should be the response of initiator to target , considering Initiator has still 1 more frame pending to transmit ?
* Initiator should Immediately close the on-going connection by DONE_CLOSE (as CREDIT_BLOCKED received is treated same as RRDY_CLOSE received message) OR
* Initiator should transmit the 4th pending frame and then close connection by DONE_NORMAL ? OR
* Initiator should Immediately close the on-going connection by DONE_CREDIT_TIMEOUT transmission ?
6.20.4 SSP flow control
* If SSP frame credit is nonzero and a persistent connection:
* has not been established;
* was established and has been disabled (see 18.104.22.168.4); or
* has been established and the Persistent Connection Timeout timer (see table 196) has expired,
then SSP phys that are going to be unable to provide additional SSP frame credit for 1 ms, even if they receive frames per the existing SSP frame credit, may transmit CREDIT_BLOCKED.
* Does above statement of transmitting CREDIT_BLOCK hold true, even when Persistent connection are not supported(*) and not established so. ?
* PERSISTENT_CAPABLE bit in IDENTIFICATION frame is 0 for Initiator as well as target.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the T10