开头先问你一个场景：你写好的算法在PC上跑得飞快，换成嵌入式平台立刻掉帧，算力明明够，瓶颈却怎么都找不到。我做过不少DSP上的高性能计算优化，最后绝大多数问题都出在同一个地方——缓存。缓存优化这个事，听着基础，实际做起来门道很多，尤其是TI OMAP-L137这类带C674x DSP内核的器件，L1P/L1D/L2可配成Cache也可配成RAM，配置和代码只要是差一点点，性能能差出几倍。这篇文章就以OMAP-L137的C674x为对象，把内存映射、缓存架构、优化步骤和排查方法完整讲清楚，适合正在做DSP/SoC开发、或者被“cache miss导致性能劣化”折磨过的工程师参考。
1. 为什么说缓存优化是高算力嵌入式设备的胜负手
1.1 存储墙：核心在等数据，而不是算得慢
先看一个很常见的现象。C674x这一代DSP的内核频率能跑到300MHz以上，浮点算力也不弱，一个周期可以完成乘加运算。但问题在于，CPU核的运算速度和外设、DDR存储器之间的访问速度严重不匹配。片内L1命中大约是1个周期，L2命中大概十几个周期，而访问片外DDR2往往要上百个周期。上百个周期是什么概念？每次cache miss，等于白白丢掉几百次乘加运算的机会。整个程序哪怕只多出几个百分点的miss率，实际吞吐量也会肉眼可见地掉下来。
这就是所谓的“存储墙”。我在项目里见过不少情况：FFT、FIR滤波、矩阵乘这类计算密集型的核心算法，汇编都已经优化到很极致了，循环展开、软件流水全做满，但性能就是上不去。后来用profile工具一查，DSP核心大部分时间都在stall，也就是等待数据从外部存储器搬运回来。这时候你已经不是在“算”，而是在“等”。高性能计算优化的目标，其实不只是减少指令周期，更是要想办法让数据尽量待在离ALU最近的地方，也就是L1、L2这些片上缓存里。
所以缓存优化并不是锦上添花，而是一道必答题。尤其当你的系统有实时性要求，比如音频处理每帧必须在固定时间内完成，或者雷达信号处理需要持续跑高吞吐量的滤波和FFT，缓存命中率直接决定了系统能不能按时完成任务。
1.2 这个思路适合谁，能解决什么问题
这篇文章具体围绕OMAP-L137和C674x展开，但方法论不只适用于这一颗芯片。OMAP-L137是TI的一颗双核处理器，内部集成了ARM9和C674x DSP。其中DSP子系统在1.2节会展开讲，不过先把它当成一个典型的“CPU+多级存储层次”就能理解：L1是离核心最近、最快但容量最小的存储，L2是速度折中的统一缓存/SRAM区，再往外就是共享RAM、DDR2这些大容量但慢速的存储。
适合读这篇文章的人，我认为是这三类。第一类，正在用OMAP-L137/L138或者TMS320C674x做产品开发的工程师，需要把DSP性能压榨出来；第二类，做通用嵌入式高性能计算的朋友，虽然平台不是DSP，但缓存分块、对齐、双缓冲这些思路完全通用；第三类，刚入门DSP开发、对“内存映射”和“Cache架构”看着就困的初学者，这篇会把底层逻辑讲清楚，避免一上来就乱配寄存器。
说到底，缓存优化解决的是三个具体问题：第一，降低cache miss率；第二，减少访存等待时间；第三，避免一致性陷阱导致的数据错乱。接下来的章节，我会先带你把OMAP-L137的存储架构看清楚，再给出一套可以直接抄作业的优化打法。
2. OMAP-L137的存储架构与C674x缓存机制拆解
2.1 内存映射速览：C674x的资源版图
搞缓存优化，第一件事就是把存储地图背熟。C674x DSP侧的内存映射，不同型号略有差异，但基本格局是一致的。以常见的OMAP-L137为例，DSP子系统内部有几块关键区域：
| 存储区域 | 常见地址范围 | 典型容量 | 作用和访问方式 |
|---|---|---|---|
| L1P（程序缓存/SRAM） | 0x11E00000附近 | 32KB | 只缓存指令，也可配置为SRAM放关键代码 |
| L1D（数据缓存/SRAM） | 0x11F00000附近 | 32KB | 缓存/存放热数据，与性能关系最大 |
| L2（统一缓存/SRAM） | 0x11800000附近 | 128KB（以型号为准） | 可整体或部分配置为Cache或SRAM，DSP的主工作区 |
| 共享RAM（SHRAM） | 0x80000000附近 | 128KB | ARM与DSP双核共享，常用于核间通信 |
| DDR2 | 0xC0000000附近 | 由外部颗粒决定 | 大容量但最慢，适合放冷数据和大块原始数据 |
注意这个表格里的地址是参考值，动手之前请一定翻开手中型号的Technical Reference Manual确认，因为OMAP-L137、L138和C6748这些器件在细节上可能不完全一样。我吃过这个亏，照着C6748的手册去配L137，调试了很久才发现是地址映射和缓存配置寄存器略有差异。
理解了内存映射之后，你就明白为什么缓存配置需要认真对待：L1总量只有64KB，L2也只有128KB左右，而数据可能很大。你要在“缓存命中率”和“存储容量”之间做权衡，甚至需要把一部分L2让给RAM，专门用来放那些不适合走Cache的临时缓冲区。
2.2 L1P、L1D、L2三种缓存的分工
C674x内部有三层存储结构，分工非常明确。L1P是程序侧的缓存，只处理指令读取。如果你的核心算法循环体比较小，能被完整装进L1P，那么取指延迟几乎可以忽略不计。反之，如果代码循环体大到溢出L1P，或者到处是跳转、函数调用，指令就会频繁从L2或者DDR重新加载，性能立刻打折扣。
L1D是数据侧的缓存，它的缓存行大小、关联度等参数都是固定的，由硬件决定。数据读写只要命中L1D，延迟基本就是1个周期。L1D最大的麻烦在于它容量只有32KB，很多算法的工作集比你想象得大得多。想提高L1D命中率，就得把循环切小，或者通过分块处理让当前访问的数据刚好落在L1D里。
L2的角色比较特殊，它既可以作为Cache使用，也可以作为SRAM直接地址访问。C674x的L2容量相对可观，实际项目中，我经常把L2的一部分配置成Cache给代码和数据用，另一部分切成SRAM，用来做双缓冲、DMA描述符这种需要确定地址、确定延迟的数据结构。这样既享受了Cache自动缓存热点数据的好处，又保留了SRAM确定性带来的低延迟和高吞吐。
2.3 CCFG寄存器：让SRAM和Cache按场景切换
C674x有一个很重要的配置寄存器叫CCFG（Cache Configuration Register），通过它可以把L1P、L1D和L2分别配置成不同的模式。常见模式包括全SRAM、全Cache、或者一部分Cache一部分SRAM的组合。不同的L2MODE位域值对应的配置，TI手册里都有表格，我这里不抄表，只讲选择思路。
什么情况下应该把某块存储做成全Cache？典型的场景是：你的程序工作集比L1/L2大，但访问有很强的局部性，也就是说同一段数据会被反复用。比如FFT的旋转因子表、滤波器系数，这种数据希望硬件自动缓存，那就把对应区域配成Cache，利用LRU替换策略保持热点数据常驻。什么情况下应该切成SRAM？两种情况。一是你的数据缓冲区需要被DMA外设访问，走Cache反而容易出一致性问题；二是某些关键变量需要确定性的访问延迟，不能哪一次突然miss导致中断处理超时。
另外还有一个绕不开的是MAR寄存器，也就是Memory Attribute Register。它控制某个地址范围到底能不能被Cache缓存。很多工程师只调CCFG，忘了MAR，结果发现外设寄存器区域被缓存了，或者共享RAM区域没被缓存，程序行为和预期完全不一致。最稳妥的做法是：外设寄存器区一律配成不可缓存，普通DDR2和共享RAM按需配置，DSP片内的L1/L2另说。这套配置是后续所有优化的地基，地基歪了，后面做再多优化都是白费。
3. 缓存优化的关键参数与代码改造方法
3.1 数据分块：让热数据留在缓存里
缓存优化里最高优先级的手段，我个人认为永远是数据分块，也就是大家常说的loop tiling。原理不复杂：一个算法要处理的数据量如果远大于L2容量，缓存就会不停地把旧数据换出去、把新数据换进来，miss率自然下不来。与其这样，不如把计算过程切成一格一格的，每次只处理一块能放进L2的小数据，处理完再换下一块。
比如处理一张较大的图像或者二维矩阵，常规的写法是两层循环一路往下扫。但如果行数很多，缓存里根本放不下那么多行，后续行必然从DDR重新读取。改成按块处理之后，每一块内部的访问都集中在一个很小的地址范围内，L2可以稳稳兜住这块热数据，命中率大幅度上升。分块的大小怎么定？基本原则是让当前计算需要的输入数据和输出数据加起来不超过L2可用容量，留一部分余量给栈和中间变量。
这里我特别想强调一个概念：算术强度（Arithmetic Intensity），定义是“每从存储读入一个字节，能进行多少次运算”。如果一个算法读一次数据只做两三次运算，那它就属于访存密集型，再怎么优化循环都没用，必须减少数据搬运次数。分块的本质，就是提高单次载入数据的复用次数，用计算换访存。
3.2 缓存行对齐与行间填充
第二个常用的手段是对齐和填充。Cache在搬运数据的时候是按行来的，常见的行大小是32字节到128字节，要先查手册确认C674x具体是多少。如果数据起始地址没有对齐到缓存行边界，一次读请求可能会触发两次缓存行填充，等于白浪费一次加载。
比如定义一个大数组，常规写法就是普通定义，编译器很可能给你分配一个不对齐的起始地址。优化的做法是使用编译器的对齐指令，比如TI CCS里常用的#pragma DATA_ALIGN(array, 128)，或者在创建缓冲区时手动把起始地址对齐到缓存行长度。对齐之后，数据每次加载都恰好落在整数个缓存行里，不会为了半个缓存行付出整行带宽的代价。
填充则是处理另一个问题：二维数组按行存储时，如果每一行的字节数恰好是缓存行大小的整数倍，缓存set冲突会比较严重。行与行之间会映射到同一个缓存set上，互相挤来挤去，导致明明数据量不大，命中率却很糟糕。解决办法是在每行的末尾人为加一些填充的空白字节，让行与行的映射错开。看似浪费了一点内存，换来的是缓存冲突大幅降低，性能收益非常可观。
3.3 双缓冲与EDMA流水
当数据量实在太大，或者源数据在外设/DDR里需要搬来搬去时，双缓冲加DMA就是我优先选的方案。思路非常简单：准备两个缓冲区A和B。CPU在计算缓冲区A里的数据时，DMA控制器同时在把下一批数据搬进缓冲区B；等A算完，CPU立刻切换到B，DMA又回头往A里搬新数据。这样两个动作重叠起来，计算和搬运互不等待，流水线就满了。
在C674x平台上，DMA通常用EDMA（Enhanced DMA）。实现时要注意几点。第一，缓冲区地址要对齐且固定，建议放在L2的SRAM区域，避免DMA搬运时和Cache发生冲突。第二，DMA描述符和中转标志千万不要放在Cache区域内，否则CPU更新标志后，DMA不一定能及时看到，甚至可能读到旧值。第三，启动下一轮搬运的时间点要控制好，过早会覆盖还没算完的数据，过晚又会让CPU闲着等数据。
伪代码大致是这样：
// 假设已经申请好两个缓冲区 buf[2] EDMA_load(buf[0]); // 先把第一块数据搬进来 for (k = 0; k < blockCount; k++) { int cur = k & 1; int next = (k + 1) & 1; if (k + 1 < blockCount) { EDMA_load(buf[next]); // 预取下一块，和计算重叠 } process(buf[cur]); // CPU处理当前块 while (!EDMA_done()) {} // 等待本次DMA完成 }这段代码真正跑到板子上时还要根据EDMA通道和中断信号做些适配，但结构就是这么个结构。双缓冲优化之后，最大的体会是CPU不再“空转等数据”，DDR带宽被持续利用起来，整体吞吐量能提升一截，而且速度基本稳定，不会因为DDR延迟抖动而忽快忽慢。
4. 实战：一块音频浮点滤波任务的缓存优化全过程
4.1 基线版本：直接在DDR上跑
空讲理论不好吸收，我拿一个实际做过的例子拆开讲。任务是在OMAP-L137上用C674x做一段多频段音频滤波，输入是一块连续的浮点采样数据，长度大约64KB到128KB，每个块要做三次不同截止频率的IIR/FIR滤波，然后输出。这类任务属于典型的访存密集型：数据量大、每次计算量相对小、需要连续顺序访问。
最初的实现非常简单粗暴：把所有数据放在DDR2里，直接把滤波函数的循环套上去跑。结果一测，单块处理耗时稳定在某个值，但总觉得不对劲——DSP核心频率并不低，计算量也不大，耗时不至于这么多。后来我把DSP的cycle计数打出来，再用profile工具看访存事件，发现cache miss率高得吓人。原因很明显：数据流太长，L2根本装不下，每次滤波器系数切换时，原来的数据早被挤出去了，全都在反复访问DDR2。
这个基线版本的价值在于给后续优化提供一个对照基准。没有基线，你根本不知道优化有没有效果、效果多大。所以不管时间多紧，我建议都先把“最朴素但是正确”的版本跑起来，记录数据和cycle数，后面每一步优化都做对比。当时我的基准数据就是：单块处理耗时为X个cycle，L2 miss率大概在40%以上。
4.2 第一步：分块+对齐的改动
第一轮改造我没有动任何滤波算法本身，只做了三件事：把数据开成大小合适的块，每块约16KB；把输入缓冲区和输出缓冲区都用#pragma DATA_ALIGN对齐到缓存行边界；用L2 SRAM里的固定区域作为每块的临时缓冲区。
分块之后的逻辑变成这样：每次从DDR里拷一个块到L2内的临时缓冲，滤波器在这个L2缓冲上连续处理三次，再把结果拷回DDR。因为L2里的缓冲是SRAM，地址固定、延迟可控，三次滤波的中间数据都留在L2里，不需要反复访问DDR。这个过程还顺便把“Cache一致性”的麻烦降到了最低——L2 SRAM不走Cache，CPU和DMA访问都在同一地址空间，看到的都是最新值。
测下来效果很明显。同样一块数据，处理周期从X降到了大约X的60%左右，L2 miss率也降到了个位数。这个结果其实不奇怪，因为算法本身没变，变的只是数据放的位置更聪明了。对于新手朋友，我特别推荐先把这一步做完，再考虑要不要上DMA。很多场景做完分块对齐就已经满足需求了，没必要把系统复杂化。
4.3 第二步：EDMA预取与双缓冲
分块之后仍有可以压榨的空间。滤波计算过程中，CPU有一段时间在纯计算，DDR搬运下一块数据的工作还没做。如果把搬运和计算串在一起，CPU仍然会等DMA或者memcpy完成。于是我在分块基础上又叠加了3.3节说的双缓冲流水。
具体改动是：申请两个L2 SRAM缓冲，先用一个EDMA通道把第一个块加载进来，然后进入主循环。循环里处理器使用当前缓冲块做滤波，同时EDMA已经在搬运下一块到另一个缓冲；处理完当前块，检查EDMA是否完成，然后立刻交换角色。这里要注意EDMA的触发时机，我用的方法是计算完成后再等待DMA完成，再启动下一个块的DMA，避免CPU和DMA错位。
这一轮优化之后，单块耗时又降了不少。到这一步，DSP核心基本一直在算，访存的等待时间被流水线掩盖住了。可能有人觉得多频段滤波这种任务计算量小，双缓冲收益有限，但实际测下来收益还是明显，原因是DDR读延迟太高，与其让CPU干等，不如让EDMA把数据提前搬到前面等着。
4.4 性能对比与收益分析
我把三个阶段的数字整理成一张表，方便直观感受。
| 阶段 | 单块处理耗时（相对值） | L2 miss率 | 说明 |
|---|---|---|---|
| 基线版 | 100% | 40%以上 | 直接在DDR上跑，无分块、无缓存配置优化 |
| 分块+对齐 | 约60% | 个位数 | 数据放L2 SRAM，地址对齐，滤波器重复使用几乎不miss |
| 加EDMA双缓冲 | 约40% | 几乎可忽略 | 计算与DDR预取重叠，CPU等待时间大幅减少 |
这个数字不是绝对值，因为它依赖输入数据量、滤波阶数和外界DDR频率，但趋势是有代表性的。大多数访存密集型任务，按“分块→对齐→双缓冲”这个顺序优化，都能看到这样的收益曲线：第一次优化解决缓存替换问题，第二次优化解决访存延迟暴露问题。后续我还试过把滤波系数放到L1D附近的SRAM里，收益已经很小，说明瓶颈已经从缓存转移到了纯计算量上。
5. 缓存优化的常见坑与排查技巧实录
5.1 缓存一致性问题：数据更新了，读到的却是旧的
缓存优化里最阴间的坑就是一致性问题，尤其是DMA和CPU共用同一块内存时。现象很典型：外设通过EDMA往一块内存里搬了新数据，DSP读到的却还是旧数据，甚至逻辑完全错乱还不报错。原因是DSP的Cache里可能还留着旧副本，CPU读内存时优先命中Cache，根本不知道数据已经被外设更新了。
解决办法是理解两个基本操作：wb（write back，把Cache里的脏数据写回内存）和inv（invalidate，把Cache里的数据标记为无效，下次读取强制从内存重新加载）。对于C674x，CSL库提供了一组现成接口，常用的像：
#include <ti/csl/csl_cacheAux.h> // 把L1D缓存中的数据写回到内存 CACHE_wbL1d(CACHE_WAIT); // 让L1D缓存中的对应地址失效，强制重新读取 CACHE_invL1d(CACHE_WAIT); // L2也是类似 CACHE_wbL2(CACHE_WAIT); CACHE_invL2(CACHE_WAIT);用的时候记住一个方向：CPU写完数据交给DMA搬走，先wb，确保数据真正落到内存；DMA搬完数据交给CPU读，先用inv，把缓存里的旧副本清掉。这里最容易漏的是双缓冲切换时忘记invalidate，导致DMA已经搬完新数据，CPU还在处理缓存里的旧块。我自己的习惯是在DMA完成中断里统一做一次invalid，不让CPU侧自己随便猜。
5.2 外设地址区忘配MAR，性能神秘下降
另一个很坑的问题出在MAR配置上。C674x默认对某些地址区域可能是不可缓存或者可缓存的，而如果不仔细看映射表，很容易踩到两种极端情况。第一种，把外设寄存器区配成了可缓存，导致CPU读状态寄存器时读到Cache里的陈旧值，外设明明已经完成中断，CPU却认为还没发生。第二种，该缓存的DDR区域被配成了不可缓存，每次读写都直接访问DDR，明明Cache很大很够用，性能却慢得像没有缓存一样。
这类问题排查起来特别折磨，因为程序逻辑表面完全正确，指令也没错，但就是性能不对或者偶尔错乱。我建议拿到新平台的第一天，就把整个内存映射表整理出来，然后逐段明确“这段是回环缓存、这段是直通访问、这段是DMA专用的SHRAM”，写进设计文档。后期再遇到性能问题，先别急着怀疑算法，而是拿这个表去核对是不是哪段区域的MAR配置和代码预期不一致。
5.3 用缓存事件计数器定位命中率
如果优化过程中你只是拍脑袋猜瓶颈，效率会低到让人崩溃。C674x提供了一些硬件事件计数器，可以统计缓存访问次数、缺失次数、流水线阻塞周期等。在CCS的Profile工具里，可以直接观察这些事件。没有CCS的时候，也可以在代码里读取相关寄存器或者使用TI的CSL接口，在优化前后各打一次点，计算差值。
使用时要注意三点。第一，统计的是全局行为还是某个函数体内的局部行为，尽量在目标函数入口和出口分别读计数器，避免把无关代码的干扰算进去。第二，事件计数器的字段宽度有限，跑太久会溢出，尽量让测试样本短一些。第三，硬件计数器本身的访问也会消耗周期，正式测性能时要把它关掉。我自己通常的做法是在一段固定输入上跑固定次数，取平均值，然后分别看“总cycle数”“L1D miss数”“L2 miss数”，哪个数字异常突出，就先顺着它往下挖。
5.4 排查顺序：先地图、再配置、后代码
最后分享一个排查流程，帮你在遇到缓存相关问题时少走弯路。第一步打开内存映射和MAR配置表，确认当前运行代码访问的地址区域是不是被缓存、被谁缓存；第二步检查CCFG的L1/L2配置比例，确认是否有空间被配置成了SRAM而你自己不知道，导致缓存容量比预期小；第三步检查数据是否对齐，特别是有没有数组横跨缓存行边界；第四步检查双缓冲流程，重点看DMA完成标志和wb/inv的顺序；第五步才轮到逐行审查算法本身。
这套流程是我在好几个项目里验证过的，每次都能把问题快速逼到某个环节。有个高频场景是：代码明明加了缓存优化，性能却不升反降。这时候十有八九是缓存配置或者一致性代码写错了，比如在循环内部频繁调用wb/inv，本来就不多的吞吐被清缓存跑开销吃掉了。这个问题在5.4里强调，是因为它比我见过的其他坑都常见。
6. 一些零散但实用的经验补充
到这一步，缓存优化的主流程已经讲完了，后面聊几个我经常被问到、也最容易忽视的小经验。
第一，优化前先建立基线，并且把“基线性能数据”像源代码一样管理起来。没有基线，你无法判断某个改动是提升还是回退。我在项目里会把每一版优化的cycle数、miss数、buffer大小、配置模式记到一个表格里，方便随时回溯。很多工程师优化到一半发现性能变差了，却说不清哪一步导致的，就是因为少了这个过程。
第二，优先改算法结构，再碰汇编和缓存参数。缓存优化是为了让算法运行得更接近存储上限，但算法本身复杂度过高时，缓存救不了你。比如一个O(n^2)的劣化算法，改成O(n log n)的算法带来的收益，比任何缓存技巧都大得多。一定要把复杂度优化放在前面，缓存优化放在后面，顺序反了事倍功半。
第三，L2 SRAM是稀缺资源，别一次性分配完。很多人一上来就把所有L2配成SRAM，结果Cache没有了，热点数据只能直接访问DDR，性能反而更差。预留一部分Cache，再留一部分SRAM做双缓冲，是比较均衡的配比。具体比例没有标准答案，和任务类型强相关，但记住一个原则：没有Cache时，你失去了自动缓存能力；没有SRAM时，你失去了确定性缓冲区，两边都别走极端。
做嵌入式高性能计算这些年，我最大的体会是：缓存优化不是靠某一个精妙技巧一步登天，而是把存储层次、数据布局、访问模式、DMA协调这些基础动作都打理好之后，性能自然就上来了。每次看到那些靠“降低cache miss率”让DSP跑满吞吐量的时刻，都觉得前期把内存映射和缓存架构翻来覆去研究透，是值得的。最后再提醒一句，动手调寄存器之前，一定先把TRM对应章节读一遍——芯片手册里的内存映射表和缓存配置表，才是你所有优化的底气。
