3. 硬件裁剪基础：SoC架构与裁剪点、外设裁剪策略、内存与存储裁剪、硬件加速器取舍
硬件裁剪，说白了就是给芯片做减法。你想想看，一个SoC里集成了那么多IP模块，真正用到的可能不到一半。我刚开始做嵌入式系统时，总觉得硬件资源越多越好，结果被成本和生产周期狠狠教育了一顿。
这一章，我们聊聊硬件裁剪的核心思路。我会结合自己踩过的坑，帮你理清SoC架构中的裁剪点、外设取舍策略、内存与存储的优化方法，以及硬件加速器到底该不该留。
3.1 SoC架构与裁剪点
SoC（System on Chip）就像一个微型城市。CPU是市政府，总线是主干道，各种外设是居民区、工厂和商店。裁剪，就是决定哪些区域该扩建，哪些该拆除。
核心裁剪点：
- CPU核心数：双核、四核还是单核？不是越多越好，功耗和面积会翻倍。
- 缓存大小：L1/L2/L3缓存，每KB都是钱。我见过一个项目，为了省成本把L2砍到16KB，结果性能直接腰斩。
- 总线宽度与协议：AXI、AHB、APB，选哪个？高带宽意味着高功耗。
- 电源域与时钟域：不必要的电源域可以合并，减少PMIC复杂度。
我个人习惯，先画一张SoC的模块依赖图。把每个IP的功耗、面积、带宽需求标出来。然后问自己三个问题：
- 这个模块在最终产品中必须存在吗？
- 有没有软件替代方案？
- 能不能用更便宜的IP替换？
举个例子。我在一个IoT网关项目中，发现原设计用了四核Cortex-A72。但实际负载分析显示，大部分时间只有一个核在跑，其他三个核基本闲置。最后我们换成了双核Cortex-A53，功耗降了40%，成本降了30%。
注意：裁剪缓存时，一定要跑真实负载的benchmark。我曾经只看datasheet就砍了L2缓存，结果系统在高峰流量时频繁缺页，最后不得不加回。嗯，这个教训挺深刻的。
3.2 外设裁剪策略
外设是SoC里最容易被过度设计的地方。很多芯片厂商喜欢堆外设，显得功能强大。但实际项目中，80%的外设可能从未被启用。
我总结了一套外设裁剪的优先级策略：
| 优先级 | 外设类型 | 裁剪建议 | 典型场景 |
|---|---|---|---|
| P0 | 核心通信接口（UART/I2C/SPI） | 必须保留，但可减少通道数 | 调试、传感器通信 |
| P1 | 高速接口（USB/PCIe/Ethernet） | 按需保留，评估带宽 | 数据上传、外设扩展 |
| P2 | 多媒体接口（HDMI/MIPI/DisplayPort） | 无显示需求可全砍 | 工业控制、纯数据处理 |
| P3 | 模拟外设（ADC/DAC/PWM） | 按精度需求裁剪 | 传感器采集、电机控制 |
| P4 | 安全模块（TEE/Secure Element） | 非安全场景可移除 | 消费电子、简单控制 |
你可能会问，怎么判断一个外设能不能砍？我的方法是：
- 看引脚复用：如果某个外设的引脚可以被其他模块复用，那它就有被砍的可能。
- 看驱动复杂度：驱动代码超过5000行的外设，维护成本高，能不用就不用。
- 看中断频率：中断太频繁的外设，会拖累CPU性能，考虑用DMA替代或直接砍掉。
小技巧：在芯片选型阶段，可以要求厂商提供“最小外设配置”的定制服务。很多大厂（如NXP、TI）都支持这种操作，只是需要提前沟通。我试过一次，把原本LQFP-144封装的芯片砍成了QFN-48，面积缩小了60%。
3.3 内存与存储裁剪
内存和存储，是系统裁剪的重灾区。很多人觉得内存越大越好，但嵌入式系统不是PC，每一MB都要精打细算。
先看一张典型的内存裁剪决策图：
内存裁剪的具体策略，我分几个层面来讲：
3.3.1 SRAM vs DRAM
SRAM速度快但贵，DRAM便宜但需要刷新。我的建议是：
- 实时性要求高的数据（如中断栈、DMA缓冲区）放SRAM。
- 大块数据（如帧缓冲、日志）放DRAM。
- 代码段：如果能从Flash直接执行（XIP），可以省掉DRAM。
3.3.2 存储介质选择
| 介质 | 优点 | 缺点 | 裁剪建议 |
|---|---|---|---|
| NOR Flash | XIP支持、高可靠性 | 容量小、价格高 | 代码小于2MB时首选 |
| NAND Flash | 容量大、成本低 | 需要坏块管理、ECC | 数据存储场景 |
| eMMC | 集成控制器、接口简单 | 体积大、功耗高 | 需要文件系统时考虑 |
| SD/NAND | 小封装、低成本 | 性能一般 | 轻量级存储 |
避坑指南：我曾经在一个项目中选了NAND Flash，但没预留足够的ECC空间。结果产品用了半年后，坏块率飙升，数据大面积损坏。后来不得不加了一颗SPI NOR做冗余。记住，NAND的坏块管理不是可选项，是必选项。
3.4 硬件加速器取舍
硬件加速器，比如GPU、VPU、NPU、DSP，是SoC里最吃面积和功耗的模块。要不要留？我的判断标准很简单：
算一算软件能不能扛得住。
举个例子。一个视频解码任务，用CPU软解需要占用80%的CPU资源，功耗2W。用硬件VPU，CPU占用降到5%，功耗0.5W。但如果你的产品只需要偶尔解码一段短视频，CPU软解完全够用，那VPU就是浪费。
我整理了一个加速器取舍的评估表：
| 加速器类型 | 典型功耗 | 面积占比 | 软件替代可行性 | 保留条件 |
|---|---|---|---|---|
| GPU | 1-5W | 15-30% | 低（UI渲染不可替代） | 有图形界面需求 |
| VPU（视频编解码） | 0.5-2W | 5-15% | 中（软解可行但功耗高） | 实时视频流处理 |
| NPU（神经网络） | 0.5-3W | 5-20% | 低（推理延迟要求高） | AI推理场景 |
| DSP（数字信号处理） | 0.1-0.5W | 2-8% | 高（CPU SIMD可替代） | 超低延迟音频/传感器 |
| 加密引擎 | 0.05-0.2W | 1-3% | 中（软件加密慢） | 有安全认证需求 |
我个人习惯，在项目初期先做一次负载画像。把系统跑起来，用perf或类似工具抓取CPU占用率最高的几个任务。如果某个任务占用了超过30%的CPU时间，而且有对应的硬件加速器，那就值得考虑保留。
一个实用技巧：很多SoC支持加速器的动态开关。比如，可以在系统空闲时关闭GPU时钟，需要渲染时再打开。这样既保留了加速能力，又不会一直耗电。我在一个手持设备上用过这个方案，待机功耗从200mW降到了50mW。
最后说一句，硬件裁剪不是一锤子买卖。芯片流片前，一定要做多轮裁剪评审。我建议至少三轮：
- 架构评审：看模块必要性。
- 功耗评审：看每个模块的功耗占比。
- 成本评审：看每个模块的die面积成本。
嗯，这一章的内容就到这里。硬件裁剪的核心，其实就是平衡——在性能、功耗、成本之间找到最适合你产品的那个点。没有标准答案，只有不断试错和优化。