TMS320C6747: low EMIFA async read speed caused by SCR multi-level cache request

My test code shows below:

int i;
volatile unsigned short data;

while(1){
// test FPGA EMIFA interface: A[13:0]
for (i = 0; i < 14; i++){ // write
*((unsigned short *)(0x60000000 + (1<<(i+1)))) = (1<<(13-i));
}
for (i = 0; i < 14; i++){ // read
data = *((volatile unsigned short *)(0x60000000 + (1<<(i+1))));
}
}

I has not change the L1P L1D L2RAM setting, they work in default setting. I use L2 RAM as normal RAM, and my program load and runs on the L2RAM.

Hello,

It does appear you are running into the read latency due to the SCR and other latencies, unfortunately. As you've already read, when the CPU issues a read instruction, it stalls until the data is returned to the EMIF, unlike writes which are "fire and forget."

Have you already tried experimenting with smaller values for R strobe, hold, and turnaround? (if your system allows for it)

Does using a long data type make a difference?

Regards,
Sahin

Performing 32-bit accesses will significantly increase your throughput, i.e. in between the two 16-bit sub-accesses you will see the programmed timings.  In fact, you could go one step further and use type 'long long' to perform a 64-bit access.

What will your accesses look like?  Are they mostly linear accesses or will you be jumping around between a lot of addresses?  Will there be large amounts of data transferred?  Will it be "bursty"?

I try 16-bit 32-bit 64-bit access, the result shows below:

This really do some help, there is no latency between sub-access, although the latency still exist after the 2 or 4 sub-access.

I think the latency cannot be avoid. So I will add some 32-bit/64-bit access in my program when there is continuous read address.

I think this latency cannot be avoid is due to the EMIFA controller is connected to the async BR7, and the data read back must go through the EMIFA->BR7(async)->SCR2->BR3/BR4->SCR1->DSP MDMA, really a long way, cost about 80 cpu clock estimated from the test timing above.

But the write access go through the same DSP MDMA---->EMIFA route. Perhaps the write access is pipelined going through the route, but the read access must be one by one, the first finished from EMIFA to DSP MDMA, then the second read access starts. In the 32/64-bit access, perhaps the sub read access can be pipelined. Is this pipeline explanation right?

I don't think the pipeline explanation is right. I think the read data go through the EMIFA---->DSP MDMA using less cycle same as the write timing. I think the latency is occurred after the EMIFA---->DSP MDMA route, in the cpu core, some more detail happened and caused the latency, the cache? or something else? Can you give me more detailed explanation about the hardware level mechanism which cause the latency?