C6678 - SRIO Retry-Packets

HR

I'm not sure what is happening, but it seems the C6678 is not accepting the packet. It may be outbound credit issue, timeout issue, configuration, incorrect dest_id, incorrect data rate, etc.  Despite all these possibilities, it may be the FPGA or the packet you are sending. 

Elush

Hi Elush,

OK, the question is why when adding delay between the packets than the Retry Packets disappear and everything works fine,

Thanks,

HR

HR

Do you check the full and/or busy bit before sending a packet from the FPGA to the C6678? You are using DIO so you should always check the LSUn_REG6 before sending anymore additional packets.

Elush

Hi Elush,

The FPGA is sending the packets to the DSP, and the Retry packets are from the DSP to the FPGA, the REG6 BUSY bit is in case where two cpu's (DSP side) are trying to access the same set of registers at the same time,

Thanks,

HR

HR

How long is the delay? Under 2.3.2.3 RX Operation of the SRIO User Guide, it states

"The data payload, if any, and header data is moved from the RX FIFO to the shared RX buffer. The targetTID field of the packet is examined to determine which core and corresponding set of registers are waiting for the response. Remember, there can be only one outstanding request per core. All payload data is moved from the shared RX buffer pool into memory through normal VBUSM operations."

Is there anyother request you are doing after you send the packet from the FPGA? Maybe the delay is needed so the previous packet can be placed in the RX buffer.

Elush

Hi Elush,

Currently the packets from the FPGA goes to one core only, How much delay is necessary between packets? shouldn't there be an error in case of resources issue?

Thanks,

HR

HR

I am attaching a GEL file to this post. A GEL file is a debugging tool used by the CCS to help the user catch any bugs. I assume you have the CCS v5.

To use the GEL file:

1. Enter into CCS Debug Mode (should be in the top right of CCS next to CCS Edit) and you have ran your program or paused your program. 2. Select Tools->GEL files 3. A GEL Files tab should open up 4. Right click in an entry under Script/Status table and select "Load Gel..." 5. Select the GEL file I have given you and wait for its status under the Script/Status table to turn to "Success". 6. Select Scripts and see all the different tests provided.

I recommend running the SRIO Errors Scan (both physical and logical).

Please let me know what you find.

Elush Shirazpour

4670.TCI6678_8_Srio_v0.13.gel

 Hi Elush,

OK, changing the FPGA packets priority from "0" to "1" or "2" or "3" solved the issue which I can't understand why, any suggestions for that?

Thanks,

HR

Hi HRi

HRi said:

I don't see any errors on the C6678 SRIO register (maybe I'm missing something), usually the Retry-Packets are sent in the case of unavailable resources or issues with the packets but again I don't see any error so what could be the issue?

What registers did you look at specifically?

Cheers2u

Hi Eddie,

All the SRIO error registers, any idea why changing the packet priority from "0" to "1", "2" or "3" solved the retry packets issue?

Thanks,

HR

Hi HRi

We also tried increasing prio and didn't get the same result. I believe our system is like yours where its point 2 point (FPGA directly connected to DSP). So prio should not make any difference.

Our retrys seem to be related to the DSP's L2 being overly utilized. We think L2 congestion causes the 4.5 K SRIO Rx buffer resource to fill and consequently cause retrys. 

I'm going to try changing megamodule priorities to see if I can force the SRIO peripheral to have higher priority over the Core.

We also did not find a bit set in any SRIO registers when a packet retry occurred.

Cheers2u

Hi HRi

You might find this info useful

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/439/t/254392.aspx

Cheers

Hi Eddie,

Thanks, Have you tried changing the megamodule priorities?

Thanks,

HR

Sure did. Check out the post. Unfortunately no difference.

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/439/p/254392/892120.aspx#892120

Cheers

Hi all,

we have designed a custom board with a FGPA sending data via SRIO to C6678 and got also a quite low bandwith. The link quality is fine and we had packet retries, too.

Since this thread was very helpful for me, but there is no final solution, I'd like to provide some hints for people facing the same problems.

First, it was very helpful to run through the GEL file, which is posted above.

Second, the hint with priorities was the key for us. Our SRIO core in the FGPA uses as default a priority of 0. The watermark register for prio 0 packets is PBM_SP(n)_IG_WATERMARK0 and the default value is 0x48 (72). This value is too high, if you are only dealing with prio 0 packets and want to achieve high bandwith, because of data nodes usage.

Thanks to E2E forum

Benny

Benny,

Thanks for providing your insight to the rest of the E2E community :)

Thanks again,

Clinton