TMS320C6678: SRIO Link problem in TMS320C6678

Hi,

Which Processor SDK RTOS are you using?

Best Regards,
Yordan

Hi, Yordan,

I am using PDK_C667X_1_1_1_4, NOT RTOS.

Thanks.

Hi, Yordan,

Could you please kindly support the case?

Thanks.

Li,

Have you tried to enable SRIO reset isolation using the CSL_PSC_enableModuleResetIsolation()?
Would it be possible that your SRIO_Interrupts_Init() reset the SRIO when a run-time error has occured? And how did you identify the SRIO is 're-initialized'?
Also do you observe the same issue with a lower data rate like 1.25Gbps?

Regards,
Garrett

Hi Garrett,

Thanks for your reply.

As you can see the shared sample code, the CSL_PSC_enableModuleResetIsolation() is not called. So may I know where can I find more detail about this function if it really helps.

Any SRIO_Interrupts_Init() Function will cause Run-time error? Or What cases may cause SRIO Link reset?

There is a logic in my FPGA to detect the SRIO Link bit 0(PORT_UNINIT), if the bit change from '0' to '1', I will regard it re-inited. Which means the SRIO link was reset after my normally Power Rest DSP.  

Of cource I will try to test that at lower data rate. But you know, I never have the problem as I boot DSP and running my code.

My operation sequence is:  FPGA Reset Power of DSP -> DSP Load EEPROM(I2C) After DSP power reset(to init DDR3, PLL, SRIO) -> FPGA Wait for SRIO Linkup(0x2) ->  FPGA WRITE/READ DDR3 of DSP Through SRIO -> Download Custom bitstream to DDR3 Throuhg SRIO -> Kick start.

The problem only happened at FPGA WRITE/READ DDR3 of DSP Through SRIO, and so far no "re-inited" problem detected after kick-start. And the problem is about 1~2%.

Thanks.

thanks.

Li,

For reset isolation, see SRIO user guide section 2.3.11 Reset Isolation for RapidIO.

Typically when run-time error has occurred, the CPU should reset/resynchronize the peripheral, see section 2.3.14 Error Handling and Logging for error cases and Port Error Status (CSR) for error captured in the register. Similar as FPGA, in the SRIO IP of C6678, link failure is considered as fatal error as well, see Table 3-87 Port Error Status CSR n Field Descriptions (Address Offset 0xB158, 0xB178, 0xB198, 0xB1B8) (Part 2 of 2): Inbound or Outbound port has encountered an error from which the hardware was unable to recover (fatal error). Write 1 to clear this bit. This bit reports the failing of design to recover from following errors:
- four link-request trials with receiving of link-response without an outstanding ackID
- four link-request trials with time-out error for link-response.

I thought you have the error handling/SRIO reset in your SRIO_Interrupts_Init().

Regards,
Garrett

Hi Garret,

Thanks for your reply and after read the User guide about the Reset isolation, I think there is no such need for my application.

As mentioned in beginning of my post, I found SRIO the status is 0x00020002 after I got the "re-inited" error.

Where the bit17 Output Error-encountered means:  "Output port has encountered (and possibly recovered from) a transmission error. This bit is set when bit 16 is set. Once set, remains set until written with a logic 1 to clear." (Table 3-87)

I never saw the bit2: Port Error. where you mentioned in previous reply.

So I am not sure why there is a transmission error and would you please hlep to explain more about the transmission errror on output port, is it due to the there is no ACK from FPGA or what else?

Besides, I only got this problem when first bootup DSP and doing DDR3 checking through SRIO. This error never encountered during normally operation, while during my normally operation the SRIO bandwidth usage rate is much higher than DDR3 Checking after bootup.

As you mentioned it may relate to the SRIO_Interrups_Inits() function, I have reviewed it, and Can not find any instuction is possible to cause the SRIO Rest as you can see the code below:

Could you please give some comment after review the code?

----------------------------------------SRIO_Interrupts_Init function---------------------------------------------------------------------------------

void SRIO_Interrupts_Init(void)
{
/*map SRIO doorbell interrupts to INT4.
map message descriptor accumulation low priority channel 0 interrupt
to INT5*/
CGEM_regs->INTMUX1 =
(CSL_GEM_INTDST_N_PLUS_16<<CSL_CGEM_INTMUX1_INTSEL4_SHIFT)|
(CSL_GEM_QM_INT_LOW_0<<CSL_CGEM_INTMUX1_INTSEL5_SHIFT);

/*Clear all DSP core events*/
CGEM_regs->EVTCLR[0]= 0xFFFFFFFF;
CGEM_regs->EVTCLR[1]= 0xFFFFFFFF;
CGEM_regs->EVTCLR[2]= 0xFFFFFFFF;
CGEM_regs->EVTCLR[3]= 0xFFFFFFFF;

//clear DSP core interrupt flag
ICR= IFR;

//enable INT4, 5
//IER = 3|(1<<4)|(1<<5);
IER = 0;

/*Interrupt Service Table Pointer to begining of LL2 memory*/
ISTP= 0x800000;

//enable GIE
TSR = TSR|1;

interrupt_cfg.interrupt_map = interrupt_map;
interrupt_cfg.uiNumInterruptMap =
sizeof(interrupt_map)/sizeof(SRIO_Interrupt_Map);

/*interrupt rate control is not used in this test*/
interrupt_cfg.interrupt_rate= NULL;
interrupt_cfg.uiNumInterruptRateCfg= 0;

//interrupt_cfg.doorbell_route_ctl= SRIO_DOORBELL_ROUTE_TO_DEDICATE_INT;
interrupt_cfg.doorbell_route_ctl= SRIO_DOORBELL_ROUTE_TO_GENERAL_INT;

srio_cfg.interrupt_cfg = &interrupt_cfg;

}

----------------------------------------------------------------------------------------------------------------------------------------------------------

Thanks a lot.

Li,

Blow is pasted from RapidIO™ Interconnect Specification Part 4: Physical Layer 8/16 LP-LVDS Specification, which explains the transmission error you observe:

-----------------

There are three types of detectable control symbol errors: a packet acknowledge error, a corrupt control symbol error, and an uncorrupted protocol violating control symbol.

A packet acknowledge error is a packet-accepted or packet-retry control symbol which has an unexpected ackID value or an unexpected packet-not-accepted control symbol. This error shall cause the receiving device to enter an “Output Error-stopped” state, immediately stop transmitting new packets, and issue a restart-from-error control symbol. The restart-from-error control symbol receives a response containing receiver internal state, including the expected ackID. This expected ackID indicates to the sender where to begin re-transmission because the interface may have gotten out of sequence. The sender shall then back up to the appropriate unaccepted packet and begin re-transmission.

------------------

Regards,

Garrett