IPNC DM8127: dsp L2 SRAM efficiency

While I'm not familiar with the IPNC RDK, I can make some general statements here:

If you can predict in advance which data you're going to need next (which is probably often the case when processing data in a streaming fashion) then using L2 as SRAM should be more efficient as you can then make a "pipelining" construction where EDMA transfers the next block of data while the DSP processes the previous block of data in parallel, thus completely hiding the cost of the data transfer.

The cache on the other hand cannot see into the future, nor does it support any kind of background preloading, so if the algorithm has poor data locality (also often the case when processing data in a streaming fashion) the DSP will spend much time stalled waiting on cache linefills.

The downside of such a pipelining construction is that it complicates the structure of software, and only applies when the structure of data access is regular enough to allow starting the EDMA transfers in advance; waiting synchronously for EDMA to complete would probably result in worse performance than relying on the cache.

Zhao Shui said:

what if I configure L2 SRAM as 256K SRAM and 0k cache,will something bad happen since I close L2 cache here?

I have DSP code running with both L2 and L1D disabled without any problems, but it is a relatively simple case since all of its "hot" data fits in L1D and all of its code in L1P.  The latter is a point to take into consideration: L2 cache is used for both code and data.  If the hot parts of your code do not fit into L1P then you're going to have costly stalls on instruction fetching if you disable L2 (or I should say, even costlier, since an L1 fill from L2 is already quite costly compared to L1 hit).