摘要
在C6000 DSP的开发过程中，优化是必不可少的一个环节，根据对象不同可以分为系统，算法，代码以及内存优化。通常，开发者熟悉自己的代码，会从前三个方面修改以获得整体性能的提升，但是对于内存尤其是缓存（Cache）的优化，因为其涉及到芯片本身的架构，Cache的维护由DSP自动完成，用户通常不能干预，所以似乎无从着手;考虑到这些实际的问题，从TI的7.0系列编译器开始支持使用缓存优化工具（Cache Layout Tools）对C6000代码进行优化，通过这一系列的工具，可以很轻松的完成L1P Cache性能的提升，本文详细介绍了该工具的使用方法。
1.引言
目前，使用TI DSP的用户越来越多，在C6000系列DSP中，包含了C64x， C64x+， C66x等。在C6000 DSP的开发过程中，为了充分利用DSP的计算资源，需要对用户程序进行优化的工作，根据对象不同可以分为系统，算法，代码以及内存优化。通常，开发者熟悉自己的系统和代码，可以比较方便的从前三个方面修改以获得整体性能的提升，但是对于内存尤其是缓存（Cache）的优化，因为其涉及到芯片本身的架构，Cache的维护由DSP自动完成，用户通常不能干预，所以似乎无从着手;考虑到这些实际的问题，从TI 的7.0 系列编译器开始支持使用缓存优化工具（Cache Layout Tools）对C6000代码进行优化，通过这一系列的工具，可以很轻松的完成L1P Cache性能的提升，本文详细介绍了该工具的使用方法。
2.C6000 DSP内核缓存机制
C6000系统的存储器结构如下图所示。
Figure 1.C6000存储器结构
存储器分成三级：第一级是L1，包括数据存储器（L1D）和代码存储器（L1P）;第二级是代码和数据共用存储器（L2以及MSMC SRAM）;第三级是外部存储器，主要是DDR存储器。L1P、L1D和L2的Cache功能分别由相应的L1P 控制器、L1D控制器和L2控制器完成。
在C6000 DSP中通常我们会把L1P全部配置成Cache，当CPU发出取指命令，首先会从L1P里查找，如果L1P找不到，则到下一级Cache或者Memory里查找，当找到需要的地址，则将其读入L1P里，CPU从中读取执行。
因为L1P Cache的大小是有限的（本文以32KB为例），而用户内存空间一般大于32KB，必须采取一种映射的方式使得所有地址都能被L1P缓存;在C6000 DSP中，L1P Cache使用地址直接映射，所有DSP 核可访问的地址对L1P Cache大小（32K）取模就能得到该地址在L1P Cache的偏移值。
如果用户代码在内存排布不合理，可能会在L1P Cache中发生反复的内容替换，下图中的例子是一个极端情况。
Figure 2. 函数的不正确排布
TOP函数中FOR循环反复调用A 函数，而A，B，C三个函数在内存地址的分布上，与32KB边界的偏移地址是一样的，因此，A，B，C将对应L1P里同一个CACHE位置;其运行流程如下
当执行A时，CPU需要把A函数调入到Cache偏移值N的位置上;
A调用B，此时调入B到Cache偏移值N 的位置上，覆盖A的代码;
B调用C，此时调入C到Cache偏移值N 的位置上，覆盖B的代码;
C返回，下一次循环调入A到Cache中覆盖C的代码。
DSP核对L1P，L2，DDR的访问速度差异很大，对L1P的访问通常在1 个时钟周期内完成，而L2平均需要3-5个周期，DDR访问需要的时间更多，因此我们应该尽量避免上述这种反复重写Cache的情况，尽可能的减少函数在Cache中的置换。
如何解决该问题？最好的解决方法则是将A，B，C在内存中连续排放，这样对Cache的操作次数将降到最低，能够有效的提高执行效率，如下图所示，只要A，B，C总的大小不超过32KB，它们在Cache中的偏移值就是连续的，不会发生覆盖的现象，即使其总和大于32KB，发生置换的也仅仅是超过32K的部分。
Figure 3. 函数的正确排布
3.内存优化工具
通过上述机制可以看到，对于L1P Cache的优化主要通过分析函数调用关系和其在内存的分布。由于用户代码日益复杂，人工分析代码调用关系和地址排布需要花费大量的时间。因此，从7.0系列编译工具开始，TI提供了一套内存优化工具（Cache Layout Tools）来帮助用户轻松快捷地解决该问题。
该工具的原理是在用户进行程序编译时打开生成分析信息选项，编译器会自动加入分析记录代码到用户程序里，之后用户在TI DSP simulator或者DSP芯片上运行该可执行文件，内置的分析代码会自动记录用户的函数调用关系及调用次数。运行的案例越多，记录的信息会更详细，优化的效果也就越好。
在得到函数运行时信息以后，就可以使用编译器工具对其进行分析，生成函数排布的顺序，最后将此排布顺序输入到编译器里重新编译原代码，生成的可执行文件就已经优化过内存排布，具体的操作可以参照以下实例。
4.实例教程
该实例主要由三个C文件组成，
实例中使用DSP计数器TSCL来统计cycle数，子函数放在sub目录下。
使用实例的步骤如下，
1.编译代码
使用TI编译器对该实例进行编译，为了产生用于profile的信息，需要在编译时增加--gen_profile_info选项。如果使用命令还形式，命令行下运行Compile.bat文件，cl6x的具体参数可以参考spru186和spru187两篇文档，一般可以在编译器的安装目录下找到他们，如C:/Program Files（x86）/Texas Instruments/C6000 Code Generation Tools 7.3.9/doc。
同时在目录下生成OBJ和ASM文件，这个和我们的实验关系不大，可以不用关注。out文件是一会需要下载到芯片里运行的可执行文件，而map文件用于帮助我们定位profile信息存放的内存地址。
如果用户使用CCS编译工具，则需要在Build的属性里指定Feedback选项，然后正常编译即可生成携带分析代码的可执行文件。
Figure 4. CCS初编译的选项
2.获取分析信息
根据用户获取分析数据的不同，这里有两种方法，第一种方法适用于持续运行的程序，比如在基于SYS/BIOS的程序里，有些任务是以循环的方式存在的，这时用户需要自己从DSP内存里读取分析数据。
首先打开map文件，可以找到.ppdata段的内存地址，这个地址就是profile信息存放处，在例子中
ppdata 0 0081fecc 00000034 UNINITIALIZED
ppdata段位于0x0081fecc这个地址，长度是34个byte。
启动CCS，连接EVM板，下载out文件到DSP上，在main函数末尾加上调试断点，可以让程序到这里暂停（实际上，在用户代码中，可以把断点设置在需要的任何地方，profile的信息是实时更新的）。
运行该程序，到达断点后，在View菜单里打开memory browser，将地址设定为0x0081fecc， 可以读到.ppdata 的信息，参考以下步骤将其存到工程目录下。
1）选取Save Memory
2）存放路径
3）确定数据地址和长度，如下图
4）修改dat文件
打开刚才存下的dat文件，注意到文件头的数据长度是以32比特字为单位的，我们需要以8比特字节为单位，如
1651 9 81fecc 0 d 1
修改为
1651 9 81fecc 0 34 1
5）转换文件格式
对刚才的运行profile信息进行分析，得到优化后的cmd 内存排布文件，该文件内容如下，用户可根据自己的程序进行修改
如果是大端，则将-le选项改为-be选项。
第二种方法，针对于只需运行一次流程的程序，CCS可以自动生成pdat文件，需要注意的是，生成pdat文件的分析代码是在用户程序结束也就是exit（）程序执行时进行，因此用户要保证自己的程序能完整运行到主函数出口结束，否则无法生成pdat文件，需要用第一种方法来获取数据。
3.重新编译代码
首先使用pdd6x从数据文件里提取prf文件作为重编译的输入文件
在命令行形式下，可以以以下形式调用输入文件生成csv文件，
在CCS环境下，只需要在CCS里指定需要的数据文件后产生csv文件，
Figure 5.CCS重编译的选项
通过调用clt6x生成内存排布
将输出的pfo.cmd加入到项目的cmd文件重新编译输出优化后的out文件，cache优化到此完成。对比优化结果，对于TCP/IP的例子应用上，CLT带来了接近20%的提升，对于视频编码等应用CLT也带来了5%左右的提升。而且，用户代码量越大，则CLT可能带来的提升越明显。
4.结论
通过使用CLT工具，可以方便快捷的对用户代码的Cache 分配进行优化，用户不需要了解DSP Cache分配的详细信息，只需要在Simulator或者硬件板卡上运行定制的代码，就可以方便快捷地得到Cache的详细信息，并自动根据这些信息对程序在内存的分布进行配置已达到提升性能的效果。
摘要
在C6000 DSP的开发过程中，优化是必不可少的一个环节，根据对象不同可以分为系统，算法，代码以及内存优化。通常，开发者熟悉自己的代码，会从前三个方面修改以获得整体性能的提升，但是对于内存尤其是缓存（Cache）的优化，因为其涉及到芯片本身的架构，Cache的维护由DSP自动完成，用户通常不能干预，所以似乎无从着手;考虑到这些实际的问题，从TI的7.0系列编译器开始支持使用缓存优化工具（Cache Layout Tools）对C6000代码进行优化，通过这一系列的工具，可以很轻松的完成L1P Cache性能的提升，本文详细介绍了该工具的使用方法。
1.引言
目前，使用TI DSP的用户越来越多，在C6000系列DSP中，包含了C64x， C64x+， C66x等。在C6000 DSP的开发过程中，为了充分利用DSP的计算资源，需要对用户程序进行优化的工作，根据对象不同可以分为系统，算法，代码以及内存优化。通常，开发者熟悉自己的系统和代码，可以比较方便的从前三个方面修改以获得整体性能的提升，但是对于内存尤其是缓存（Cache）的优化，因为其涉及到芯片本身的架构，Cache的维护由DSP自动完成，用户通常不能干预，所以似乎无从着手;考虑到这些实际的问题，从TI 的7.0 系列编译器开始支持使用缓存优化工具（Cache Layout Tools）对C6000代码进行优化，通过这一系列的工具，可以很轻松的完成L1P Cache性能的提升，本文详细介绍了该工具的使用方法。
2.C6000 DSP内核缓存机制
C6000系统的存储器结构如下图所示。
Figure 1.C6000存储器结构
存储器分成三级：第一级是L1，包括数据存储器（L1D）和代码存储器（L1P）;第二级是代码和数据共用存储器（L2以及MSMC SRAM）;第三级是外部存储器，主要是DDR存储器。L1P、L1D和L2的Cache功能分别由相应的L1P 控制器、L1D控制器和L2控制器完成。
在C6000 DSP中通常我们会把L1P全部配置成Cache，当CPU发出取指命令，首先会从L1P里查找，如果L1P找不到，则到下一级Cache或者Memory里查找，当找到需要的地址，则将其读入L1P里，CPU从中读取执行。
因为L1P Cache的大小是有限的（本文以32KB为例），而用户内存空间一般大于32KB，必须采取一种映射的方式使得所有地址都能被L1P缓存;在C6000 DSP中，L1P Cache使用地址直接映射，所有DSP 核可访问的地址对L1P Cache大小（32K）取模就能得到该地址在L1P Cache的偏移值。
如果用户代码在内存排布不合理，可能会在L1P Cache中发生反复的内容替换，下图中的例子是一个极端情况。
Figure 2. 函数的不正确排布
TOP函数中FOR循环反复调用A 函数，而A，B，C三个函数在内存地址的分布上，与32KB边界的偏移地址是一样的，因此，A，B，C将对应L1P里同一个CACHE位置;其运行流程如下
当执行A时，CPU需要把A函数调入到Cache偏移值N的位置上;
A调用B，此时调入B到Cache偏移值N 的位置上，覆盖A的代码;
B调用C，此时调入C到Cache偏移值N 的位置上，覆盖B的代码;
C返回，下一次循环调入A到Cache中覆盖C的代码。
DSP核对L1P，L2，DDR的访问速度差异很大，对L1P的访问通常在1 个时钟周期内完成，而L2平均需要3-5个周期，DDR访问需要的时间更多，因此我们应该尽量避免上述这种反复重写Cache的情况，尽可能的减少函数在Cache中的置换。
如何解决该问题？最好的解决方法则是将A，B，C在内存中连续排放，这样对Cache的操作次数将降到最低，能够有效的提高执行效率，如下图所示，只要A，B，C总的大小不超过32KB，它们在Cache中的偏移值就是连续的，不会发生覆盖的现象，即使其总和大于32KB，发生置换的也仅仅是超过32K的部分。
Figure 3. 函数的正确排布
3.内存优化工具
通过上述机制可以看到，对于L1P Cache的优化主要通过分析函数调用关系和其在内存的分布。由于用户代码日益复杂，人工分析代码调用关系和地址排布需要花费大量的时间。因此，从7.0系列编译工具开始，TI提供了一套内存优化工具（Cache Layout Tools）来帮助用户轻松快捷地解决该问题。
该工具的原理是在用户进行程序编译时打开生成分析信息选项，编译器会自动加入分析记录代码到用户程序里，之后用户在TI DSP simulator或者DSP芯片上运行该可执行文件，内置的分析代码会自动记录用户的函数调用关系及调用次数。运行的案例越多，记录的信息会更详细，优化的效果也就越好。
在得到函数运行时信息以后，就可以使用编译器工具对其进行分析，生成函数排布的顺序，最后将此排布顺序输入到编译器里重新编译原代码，生成的可执行文件就已经优化过内存排布，具体的操作可以参照以下实例。
4.实例教程
该实例主要由三个C文件组成，
实例中使用DSP计数器TSCL来统计cycle数，子函数放在sub目录下。
使用实例的步骤如下，
1.编译代码
使用TI编译器对该实例进行编译，为了产生用于profile的信息，需要在编译时增加--gen_profile_info选项。如果使用命令还形式，命令行下运行Compile.bat文件，cl6x的具体参数可以参考spru186和spru187两篇文档，一般可以在编译器的安装目录下找到他们，如C:/Program Files（x86）/Texas Instruments/C6000 Code Generation Tools 7.3.9/doc。
同时在目录下生成OBJ和ASM文件，这个和我们的实验关系不大，可以不用关注。out文件是一会需要下载到芯片里运行的可执行文件，而map文件用于帮助我们定位profile信息存放的内存地址。
如果用户使用CCS编译工具，则需要在Build的属性里指定Feedback选项，然后正常编译即可生成携带分析代码的可执行文件。
Figure 4. CCS初编译的选项
2.获取分析信息
根据用户获取分析数据的不同，这里有两种方法，第一种方法适用于持续运行的程序，比如在基于SYS/BIOS的程序里，有些任务是以循环的方式存在的，这时用户需要自己从DSP内存里读取分析数据。
首先打开map文件，可以找到.ppdata段的内存地址，这个地址就是profile信息存放处，在例子中
ppdata 0 0081fecc 00000034 UNINITIALIZED
ppdata段位于0x0081fecc这个地址，长度是34个byte。
启动CCS，连接EVM板，下载out文件到DSP上，在main函数末尾加上调试断点，可以让程序到这里暂停（实际上，在用户代码中，可以把断点设置在需要的任何地方，profile的信息是实时更新的）。
运行该程序，到达断点后，在View菜单里打开memory browser，将地址设定为0x0081fecc， 可以读到.ppdata 的信息，参考以下步骤将其存到工程目录下。
1）选取Save Memory
2）存放路径
3）确定数据地址和长度，如下图
4）修改dat文件
打开刚才存下的dat文件，注意到文件头的数据长度是以32比特字为单位的，我们需要以8比特字节为单位，如
1651 9 81fecc 0 d 1
修改为
1651 9 81fecc 0 34 1
5）转换文件格式
对刚才的运行profile信息进行分析，得到优化后的cmd 内存排布文件，该文件内容如下，用户可根据自己的程序进行修改
如果是大端，则将-le选项改为-be选项。
第二种方法，针对于只需运行一次流程的程序，CCS可以自动生成pdat文件，需要注意的是，生成pdat文件的分析代码是在用户程序结束也就是exit（）程序执行时进行，因此用户要保证自己的程序能完整运行到主函数出口结束，否则无法生成pdat文件，需要用第一种方法来获取数据。
3.重新编译代码
首先使用pdd6x从数据文件里提取prf文件作为重编译的输入文件
在命令行形式下，可以以以下形式调用输入文件生成csv文件，
在CCS环境下，只需要在CCS里指定需要的数据文件后产生csv文件，
Figure 5.CCS重编译的选项
通过调用clt6x生成内存排布
将输出的pfo.cmd加入到项目的cmd文件重新编译输出优化后的out文件，cache优化到此完成。对比优化结果，对于TCP/IP的例子应用上，CLT带来了接近20%的提升，对于视频编码等应用CLT也带来了5%左右的提升。而且，用户代码量越大，则CLT可能带来的提升越明显。
4.结论
通过使用CLT工具，可以方便快捷的对用户代码的Cache 分配进行优化，用户不需要了解DSP Cache分配的详细信息，只需要在Simulator或者硬件板卡上运行定制的代码，就可以方便快捷地得到Cache的详细信息，并自动根据这些信息对程序在内存的分布进行配置已达到提升性能的效果。
举报
