4、工作负载分析：如何获取和分析目标应用的工作负载特征，Benchmark的选择与裁剪
做SoC选型，最怕什么？
怕拍脑袋。怕拿着别人的PPT数据，直接套在自己的项目上。
我见过太多团队，芯片选型时只看峰值算力，结果流片回来发现——内存带宽不够，或者NPU利用率不到30%。说白了，就是没搞清楚自己的应用到底在跑什么。
这一章，我们就聊聊工作负载分析。这是整个架构建模的起点，也是决定选型成败的关键一步。
4.1 为什么要做工作负载分析？
你想想看，SoC是一个平台。它要跑你的算法、你的协议栈、你的实时任务。不同应用对计算、存储、通信的需求天差地别。
举个例子：
- 一个视频编解码芯片，瓶颈通常在内存带宽和编解码器流水线。
- 一个AI推理芯片，瓶颈可能在MAC阵列利用率、数据搬运效率。
- 一个工业控制MCU，瓶颈往往是中断响应延迟和GPIO翻转速度。
如果不做工作负载分析，你连瓶颈在哪都不知道。选型就成了盲人摸象。
核心观点：工作负载分析的目标，是回答三个问题——
- 应用的计算特征是什么？（计算密集型？访存密集型？控制密集型？）
- 应用的并行度有多高？（数据级并行？任务级并行？指令级并行？）
- 应用的实时性要求有多严？（硬实时？软实时？尽力而为？）
4.2 工作负载分析的三个层次
我个人习惯把工作负载分析分成三个层次。由粗到细，逐步收敛。
4.2.1 宏观分析：应用场景画像
这一步不需要跑代码。只需要搞清楚：
- 你的系统要处理哪些任务？
- 每个任务的输入输出数据量多大？
- 任务之间的依赖关系是怎样的？
- 峰值负载和平均负载的差异有多大？
我在做智能座舱芯片选型时，第一步就是拉出所有功能模块：语音识别、导航渲染、仪表显示、360环视...然后给每个模块打上标签：计算型、IO型、实时型。这样一张表出来，选型方向就清晰了。
4.2.2 微观分析：热点函数识别
这一步需要跑代码了。用profiling工具（比如perf、gprof、VTune）去抓热点。
重点关注：
- 哪些函数消耗了最多的CPU周期？
- 哪些函数触发了最多的cache miss？
- 哪些函数有大量的分支预测失败？
我曾经帮一个客户做ADAS芯片选型。他们一直觉得算力不够，想换更贵的芯片。我让他们跑了一下profiling，发现80%的时间花在了一个图像预处理函数上——那个函数里有个嵌套循环，每次都在做无效的边界检查。优化掉之后，算力需求直接降了40%。
4.2.3 动态分析：运行时行为追踪
这一步更细。要追踪程序在运行时的行为模式：
- 内存访问模式（顺序访问？随机访问？步长访问？）
- 线程同步开销（锁竞争严重吗？）
- 中断频率和中断处理时间
嗯，这里要注意。很多工程师只做静态分析，忽略了动态行为。结果选型时选了高主频的CPU，但实际跑起来因为频繁的cache miss，性能还不如低主频但大缓存的芯片。
4.3 Benchmark的选择与裁剪
有了工作负载特征，下一步就是找Benchmark来量化评估。
但问题来了——市面上的Benchmark太多了。CoreMark、SPEC、MLPerf、EEMBC...每个都号称自己是标准。但直接拿过来用，往往水土不服。
避坑指南：我曾经直接拿MLPerf的完整模型去评估一个边缘AI芯片。结果跑了三天没跑完，因为模型太大，芯片内存装不下。后来我才意识到——Benchmark不是越大越好，而是要能代表你的真实负载。
4.3.1 Benchmark的选择原则
我建议遵循三个原则：
- 相关性原则：Benchmark的计算特征要和你的应用匹配。做语音识别，就别拿图像分类的Benchmark。
- 可移植性原则：Benchmark要能在目标SoC上顺利编译和运行。有些Benchmark依赖特定的库或指令集，移植起来很麻烦。
- 可裁剪性原则：Benchmark要能按需裁剪。只保留和你应用相关的子集，去掉无关部分。
4.3.2 Benchmark的裁剪方法
裁剪不是简单删代码。我一般按以下步骤来：
- 第一步：提取核心算子。从你的应用中提取出最耗时的几个算子。比如AI推理中的卷积、全连接、激活函数。
- 第二步：匹配Benchmark中的对应算子。在Benchmark中找到相同或相似的算子实现。
- 第三步：调整数据规模。把Benchmark中的输入数据大小改成和你应用一致。不要用1Kx1K的矩阵去测一个实际只用64x64的应用。
- 第四步：验证裁剪后的结果。跑一下裁剪后的Benchmark，看结果是否和原始Benchmark的趋势一致。
小技巧：裁剪后的Benchmark，最好保留一个“完整性检查”。比如计算结果的校验和，确保裁剪没有引入错误。
4.4 实战案例：一个AI推理芯片的工作负载分析
讲个真实案例吧。我之前帮一家创业公司做AI推理芯片的选型。他们的应用是智能摄像头，主要做目标检测。
我们做了三步：
- 宏观分析：确定核心负载是YOLOv5s模型，输入分辨率640x480，帧率30fps。计算量约4.5GFLOPs每帧。
- 微观分析：用profiling工具发现，卷积层占了92%的计算时间。其中3x3卷积占了70%，1x1卷积占了22%。
- Benchmark裁剪：从MLPerf中提取了MobileNetV2的卷积子集，把输入尺寸改成640x480，通道数按YOLOv5s的配置调整。
最终我们用裁剪后的Benchmark，在3款候选芯片上跑了性能。结果发现，有一款芯片虽然峰值算力高，但小卷积核的利用率很低——因为它的MAC阵列是专为大矩阵设计的。这个发现直接帮客户省了30%的芯片成本。
4.5 工作负载分析的知识体系
下面这张图，是我总结的工作负载分析核心逻辑。你可以把它当作一个检查清单。
这张图的核心逻辑是：从目标应用出发，经过三个层次的分析，得到工作负载特征。然后基于这个特征去选择和裁剪Benchmark。最后用Benchmark的结果来支撑SoC选型决策。
每一步都不能跳。跳了，选型就容易翻车。
4.6 本章小结
工作负载分析，说白了就是搞清楚你的应用到底在干什么。它不是什么高深的理论，而是一套务实的方法论。
我个人觉得，做SoC选型最忌讳的就是「拿来主义」。别人用CoreMark跑800分，你就觉得自己的芯片也能跑800分。但你的应用可能全是浮点运算，CoreMark测的是整数性能——这能一样吗？
所以，花时间做工作负载分析，绝对值得。它可能只占你选型周期的20%时间，但能影响80%的决策质量。
一句话总结：没有工作负载分析的SoC选型，就是赌博。做了分析，你才能把选型变成科学。
公众号:蓝海资料掘金营，微信deep3321