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.

TMS320C6678: TMS320C6678  contention issue-

Part Number: TMS320C6678

we started encountering few problems in executing specific applications in - DSP TMS320C6678  . Below is summery in brief with background information. 

Do let us know if we need meeting to discuss in more detail.

 

Problem Description:

 

In our application, our scheduler runs tasks at three different cycle times. A timer interrupt will run these three levels at 200, 1000 and 4000us intervals. Let's call them Level 1, 2 and 3.

On Level 1, we use EDMA for handling data that is transferred to another unit through PCIe.

Apart from these three levels, we have an interrupt controlled by SRIO. This runs every 100us, controlled by a SRIO doorbell sent from an FPGA. What we have seen is, that sometimes, the SRIO tasks are delayed by about 13us. One theory is that the usage of EDMA and PCIe on Level 1 causes this delay.

 

1. So, can the EDMA/PCIe operations cause a delay on the SRIO and if so, what could we do to prevent it?

 

If we try to illustrate the TeraNet usage for Level 1 (green) and SRIO interrupt (red) in the functional block diagram:

 

 

Both applications access the Multicore Shared Memory and even if the TeraNet should be nonblocking and contention-free, can this be the problem? Or could it be our configuration of the Multicore Navigator?

We have made some attempts to down prioritize the EDMA through queue priority register (QUEPRI). We have also tried to lower the read rate to “make room for” the SRIO communication but with seemingly no effect.

It should be mentioned that the above applications run on CorePac0 but we have applications running on all eight CorePacs.

 

2. Also, since parts of the code running on CorePac4 is placed in L3 memory, could this affect the performance on CorePac0?