RTOS/TDA2EVM5777: VLIB Test Report memory design

ZM,

The values in the test report are obtained when running the tests using the DSP cycle accurate simulator on CCS5.x.  It is effectively the performance assuming that all code, stack, data are in L1 RAM; what we call flat memory model.  It only accounts for the performance of the DSP core with NO memory hierarchy stalls.  As such, this is typically a best case baseline which a real world system can only hope to get close to based on how the memory system is defined.

In this way, the numbers are helpful in comparing the core performance with each other, and gives an upper bound as to the performance you can get close to based on memory model optimizations, such as cache configuration or using DMA to bring in data into L2SRAM or L1D SRAM.

I have attached a spreadsheet which summarizes the test performance, when run in on VLIB 3.3.0.1 release, on a sample of different memory models, to give you a better idea of what to expect based on the memory model you are using.  The memory configuration number in the spreadsheet corresponds to the following legend:

perf_vlib_3_3_0_1_C66_tda2.xlsx

Memory configuration of test

1. Simulator - flat memory modoel. Cycles assume all of data/code accesses are in L1 memories.  This is to serve as a baseline which indicates the best possible performance on the particular DSP.

2. L2 Cache = 256kB, all code and data in DDR - pure cache memory model.

3. L2 Cache = 128kB, all code in DDR, data buffers in L2RAM - on TDA2x, this means 128k+32k RAM for buffers. 

4. L2 Cache = 64kB, all code in DDR, data buffers in L2RAM - on TDA2x, this means 192k+32k RAM for buffers.  

5. L2 Cache = 32kB, all code in L2RAM, data buffers in L2RAM -  on TDA2x, this means 224k+32k minus size of code RAM for buffers, .  

I presume you are using the option 2 by default: All code and data in DDR with cache.  As you can see from the spreadsheet, this is typically the worst performance (unless you have cache turned off).  Options 3-5 are meant to reflect if DMA is used to move data from DDR into L2SRAM, so the processing can happen on data already in L2SRAM.  This removes the expensive L2 data cache miss penalty on the data access, and leaves only the L1 cache miss penalty.

Hopefully, this spreadsheet can help you determine if it is worthwhile for you to make memory movement optimizations such as using DMA to move data to L2 or L1 data.

If you are still seeing a significant delta, you may want to consider the system and DDR clocks you are using, as this performance is measuring DSP clock cycles.  If DDR clock is set to lower, then the number of DSP clocks may go up due to the additional memory system stall cycles imposed by lower DDR clock. I am using the default clock settings from the CCS gel file for TDA2x.

Best Regards,

Jesse