This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SRIO LSU Busy Issue



Hi Support,

 

TI DSP : C6638 Kepler

CCS ver : 5.5

MCSDK : mcsdk_bios_3_01_01_04

 

I am using the DSP C6638 SRIO interface with IDT switch to communication with other DSP C6482.

With the Nwrite transaction only sometimes I get the SRIO LSU Hang such that no shadow registers are available.

I using the LSU flush to clear the stuck transactions temporarily.

 

Queries:-

1. What is the behaviour of SRIO SP_RT_CTL ? (currently using the default value as example). After the timer expiry will it discard the ongoing transaction or not ?

2. What is the default DMA clock period in below equation?

Timeout = 15 x((Prescale Value + 1) x DMA Clock Period x Timeout Value).

I am using :- PRE_SCALER_SELECT = 0x8, PRE_SCALAR_CLOCK = 0x10  // 156.25 Mhz, PORT_RESPONSE_TIMEOUT = 0xFF0FFF

2. After SRIO Flush , further SRIO transactions work normally. Why ?

3. How can I check the TX/RX buffer status ?

 

Regards,

Mahesh

 

  • Hi,

    Ans1: If time expires, an error should be logged in the ERROR MANAGEMENT RapidIO registers. The response timeout is handled exactly like any other error condition. The LSU will wait for the CPU to send it a flush or a restart command. The RapidIO specification states that the maximum time interval (all 1s) equates between three and six seconds. For more information refer section "2.3.2.5.1 Timeout" on SRIO user guide document.

    Ans2:

    Ans3: When the CPU issues a flush or restart command (described below) for an LSU, the context specific Completion Code bits for that LSU are reset back to “000”. The reset value of all the RIO_LSU_STAT_REG0-5 is zeros. For more information refer SRIO user guide document.

    Ans4: For WRITE commands, the payload is combined with the header information from the control/command registers and buffered in the shared TX buffer resource pool. Finally, it is forwarded to the TX FIFO for transmission. READ commands have no payload. In this case, only the control/command register fields are buffered and used to create a RapidIO NREAD packet, which is forwarded to the TX FIFO. Corresponding response packet payloads from READ transactions are buffered in the shared RX buffer resource pool when forwarded from the receive ports. Both posted and non-posted operations rely on the OutPortID command register field to specify the appropriate output port/FIFO.

    Thanks,