TI_DSP_SRIO - useful_Q&A.

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/123812.aspx  

 Q:

1).- In the two SRIO examples found in the pdk_C6678_1_0_0_11 there is no use of the Response packet Ftype 13. Could you tell me, please, why you didn't use the response packet even when it is required by the standard? ( I understand that SRIO requires response for some of the implemented FType in you examples).

2).- Where is possible to find an example of Doorbell use?

A:

1).  Just to be clear, not all SRIO packet types require responses.  For example NWRITE and SWRITE have no responses.  The example may only use these types of packets, but you can easily change the packet type to NWRITE_R or NREAD, which will use response packets.  Not sure if I missed you point or not.  The other thing to mention is that responses are sent by the SRIO peripheral hardware automatically.  The CPU doesn't have to get involved at all, there is no way to create a type 13 packet using the LSU or TXU blocks.

2).  Not sure if the doorbell is included in the example or not, but you can easily use the LSU to send a doorbell in one of two ways: You can simply create an outgoing doorbell, by writing the ftype, ttype, and doorbell info fields of the LSU registers; or you can have the LSU automatically send a doorbell after a data packet transmission by writing the doorbell info field and the int_req bit of the LSU.  It will then send the data packet followed by a doorbell packet.

Q:

1).-  How to see the feedback that the transfer has been performed without errors?  If I don't have the possibility for seeing the response Ftype 13, should be a way to see for each case that requires response that the data transferring has been performed.

2). - Are there registers for seeing this information?

3). - How to see it for the case of NWRITE_R or NREAD?

4). - How to see for the case of message type (FType 11)?

5).- In case of transmit error, the application must retransmit or the SRIO will perform it automatically?

6).- In case that the SRIO will perform the retransmition automatically and not the application, could you tell me, please, how is defined retries quantity?

A:

1) . Please refer to “http://focus.ti.com/lit/ug/sprugw1/sprugw1.pdf” section 2.3.2, pg 2-29 and 2-30.  You can determine the transaction completion by looking at:  LCB and LTID in the LSU register 6 in conjunction with RIO_LSU_STAT_REG0-5 (offset 0DE8h - 0DFCh) will give you the completion code for your transaction.

2) .Yes listed above.

3). Depends how you implement it, but you can poll these registers, or count interrupts.

4) .Any type 11 message that returns an error or if there was an error programming the TX descriptor that prevents the message from being sent, will be sent to a garbage queue.  There are various causes, just do a search for garbage in section 2.3.3.2 of the user's guide.

5). Lets clarify on this one, are you talking physical layer errors like CRC, or are you talking about logical layer error completion codes in the LSU?  Physical layer errors are handled automatically by hardware and retransmitted, logical errors will have to be resubmitted by the software.

6) .There are port status registers that indicate a physical layer Retry occurred, but not a running count.