从存储墙到Cache Miss：C674x嵌入式缓存优化实战

开头先问你一个场景你写好的算法在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程序缓存/SRAM0x11E00000附近32KB只缓存指令也可配置为SRAM放关键代码L1D数据缓存/SRAM0x11F00000附近32KB缓存/存放热数据与性能关系最大L2统一缓存/SRAM0x11800000附近128KB以型号为准可整体或部分配置为Cache或SRAMDSP的主工作区共享RAMSHRAM0x80000000附近128KBARM与DSP双核共享常用于核间通信DDR20xC0000000附近由外部颗粒决定大容量但最慢适合放冷数据和大块原始数据注意这个表格里的地址是参考值动手之前请一定翻开手中型号的Technical Reference Manual确认因为OMAP-L137、L138和C6748这些器件在细节上可能不完全一样。我吃过这个亏照着C6748的手册去配L137调试了很久才发现是地址映射和缓存配置寄存器略有差异。理解了内存映射之后你就明白为什么缓存配置需要认真对待L1总量只有64KBL2也只有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有一个很重要的配置寄存器叫CCFGCache 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立刻切换到BDMA又回头往A里搬新数据。这样两个动作重叠起来计算和搬运互不等待流水线就满了。在C674x平台上DMA通常用EDMAEnhanced 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个cycleL2 miss率大概在40%以上。4.2 第一步分块对齐的改动第一轮改造我没有动任何滤波算法本身只做了三件事把数据开成大小合适的块每块约16KB把输入缓冲区和输出缓冲区都用#pragma DATA_ALIGN对齐到缓存行边界用L2 SRAM里的固定区域作为每块的临时缓冲区。分块之后的逻辑变成这样每次从DDR里拷一个块到L2内的临时缓冲滤波器在这个L2缓冲上连续处理三次再把结果拷回DDR。因为L2里的缓冲是SRAM地址固定、延迟可控三次滤波的中间数据都留在L2里不需要反复访问DDR。这个过程还顺便把“Cache一致性”的麻烦降到了最低——L2 SRAM不走CacheCPU和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根本不知道数据已经被外设更新了。解决办法是理解两个基本操作wbwrite back把Cache里的脏数据写回内存和invinvalidate把Cache里的数据标记为无效下次读取强制从内存重新加载。对于C674xCSL库提供了一组现成接口常用的像#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对应章节读一遍——芯片手册里的内存映射表和缓存配置表才是你所有优化的底气。