TI has improved the high-performance C64x core, greatly improving its performance, and called it the C64x+DSP core. All components of the DSP chip developed based on the C64x+ core are connected with the switching network (SCR) as the core. The components on the SCR are divided into two categories: Master and Slave. The Master includes the Core, EDMA, and peripherals such as serial high-speed IO (sRIO), EMAC, etc. The Master can directly initiate data transmission to the Slave through the SCR. The Slave includes the memory of each Core, DDR2 external memory, and other peripherals that cannot directly initiate data transmission. Data transmission between Slaves needs to be assisted by DMA. The data manuals of various C64x+DSP-based models describe the configuration of the SCR and the status of the Master and Slave in detail.
The memory block diagram of the C64x+ system is shown in Figure 1. The memory is divided into three levels: the first level is L1, which includes data memory (L1D) and code memory (L1P); the second level is the shared memory for code and data (L2); the third level is external memory, mainly DDR2 memory. The CACHE functions of L1P, L1D and L2 are completed by the corresponding L1P controller, L1D controller and L2 controller respectively. Table 1 summarizes the available CACHE on the C64x+ platform.
Figure 1 C64x+ memory block diagram
Table 1 C64x+ CACHE features
On the C64x+ platform, L1P is used to store or cache code; L1D is used to store or cache data. L1P and L1D are both 32K bytes in size, and can be configured as 0K, 4KB, 8KB, 16KB or 32KB as CACHE, and the rest as code or data RAM. As part of the CACHE, it is used to cache L2 and DDR2 data or code. As part of the RAM, it can store key code or data so that the Core can run at a very high speed
On the C64x+ platform, L2 memory can be used to store code and data. A maximum of 256K bytes of cache can be allocated on L2 to cache data or code in DDR2. The rest of L2 is used as RAM to store code and data.
Figure 2 describes the operation flow of the Core accessing the memory content. In this access process, the Core's access to the memory always starts from the first-level memory closest to the Core. If it hits, the Core can directly obtain the code/data, otherwise the code/data will be loaded into the previous levels of CACHE, so that the Core can obtain the code/data to be processed. In this dynamic access process, the content in each level of CACHE may be inconsistent with the content in the next level of memory. This transient inconsistency will not cause problems. However, if the Core or other Master cannot obtain the content of the memory content updated by the other party, a CACHE consistency problem will arise.
Figure 2 Core access memory process
|