Query on usage of Cache_Inv() with no_wait

In my experiment, when i profile across cache_inv(10240 bytes) with or without wait flag, cycles consumed by the DSP is same. There is no influence of the wait flag. 

I am using CCSv5 with xdc tools_3_22_04_06. please let me know what could cause this issue

- Jeeva

Your experiment must measure one call to Cache_inv().

Back to back calls to Cache_inv() will internally wait for the previous Cache_inv() operation to complete before executing the current request.

Alan

yes I measured just one call

-Jeeva

Please share the code you are using to measure the API times as well as the measured values.

Alan

Which device or which Cache are you using?  I assume either C64P or C66, which one?

Judah

Alan and Judah,

The device being used here is TMS320C66Shn with 8 cores. Code usage is as follows

pu1_ptr, this is the Sl2 memory pointer

/*first block*/

Cache_inv(pu1_ptr,  10240, Cache_Type_ALL, (Bool)FALSE);

cache_wait();

while(end of processing)

{

start = TSCL;

/*second or n+1 th block*/

Cache_inv(pu1_ptr,  10240, Cache_Type_ALL, FALSE);

End = TSCL;

Inv_Cycles = End - start; 

{

algorithm  uses first or nth block Sl2 memory 

}

start = TSCL;

Cache wait() /* for second block or n+1*/

End = TSCL;

Wait_Cycles = End - start; 

}

The above code is scheduled across 8 cores and profiling is done for each core.

As I am using seperate cache_wait() operation after each invalidate, my assumption here is Inv_Cycles should be only the cache invalidation start time, invalidation time should be under wait_cycles. but I am seeing Inv_cycles are higher as shown below and wait cycles are negligible and there is no difference between wait flag as true or false.

Thanks Judah.

By making Cache.atomicBlockSize = 0, now cache invalidate call takes less cycles. and now I can schedule this better to improve performance.

But I have a doubt regarding the workaround mentioned in Advisory 14

In my project,  MSMC RAM is configured as Share L3 mode which is cached first in L2 then L1 D. My design uses most of the time “cache invalidate” of Sl2 data in L2.

Advisory 14 from the Silicon errata sprz331a says that

"The workaround requires that the memory system be idle during the block coherence operations. Hence programs must wait for block coherence operations to complete before continuing.This applies to L1D and L2 memory block coherence operations."

Will "Cache.atomicBlockSize = 0;" break the workaround done to avoid the cache corruption?

is it safe to use delayed cache wait with "Cache.atomicBlockSize = 0"?

-Jeeva

Workaround 2 mentioned in advisory 32 is as follows

 This workaround is also generic, but will allow CPU traffic to go on in parallel with
cache coherence operations. To issue a block coherence operation, follow the sequence
below:
1. Issue a MFENCE command.
2. Freeze L1D cache.
3. Start L1D WBINV.
4. Restart CPU traffic.
(CPU operations happen in parallel with WBINV)
5. Poll the WC register until the word count field reads as 0.
6. WBINV completes when word count field reads 0.
7. Issue an MFENCE command

so as a programmer, do I need to follow the above steps while using cache operations? or  is it taken care inside  cache API calls itself?

-Jeeva

Thank You Judah :-)