3. 算法选型与可行性分析
好，咱们进入第三个关键环节。需求明确了，系统方案也定了，接下来就是挑算法、算资源、写报告。这一步做不好，后面开发到一半发现算力不够、内存爆了，那可就尴尬了。我见过太多项目死在这上面。
3.1 常见SOC算法：三类典型代表
SOC里跑的算法，说白了就三大类：信号处理、控制、AI推理。咱们一个一个说。
3.1.1 信号处理类算法
这类算法最老牌，也最成熟。比如FFT、FIR/IIR滤波器、CORDIC、卡尔曼滤波。它们的特点是：计算模式固定，数据流清晰，非常适合硬件加速。
我个人的习惯是：只要能用信号处理解决的问题，绝不用AI。为什么？因为信号处理算法的功耗和延迟是确定的，好算。AI那玩意儿，你想想看，模型大小、推理时间，都得靠实测才能摸清。
典型例子：麦克风阵列的波束成形。用延时求和（Delay-and-Sum）算法，复杂度O(N)，硬件实现简单。但如果你非要用深度学习来做，那功耗至少翻3倍。
3.1.2 控制类算法
PID、MPC（模型预测控制）、LQR这些。控制算法对实时性要求极高，通常跑在RTOS或者裸机上。我在项目中遇到过一个问题：PID的积分项饱和，导致系统震荡。后来加了抗饱和（Anti-Windup）机制才解决。
控制算法的选型，核心看两点：
- 响应速度：控制周期是1ms还是10ms？决定了你用简单PID还是复杂MPC。
- 模型精度：系统模型准不准？不准的话，MPC效果还不如调好的PID。
避坑指南：我曾经在一个电机控制项目里，为了追求“先进”选了MPC，结果模型参数标定花了两个月，最后发现PID加个前馈就能满足指标。嗯，有时候简单就是美。
3.1.3 AI推理算法
这几年最火的。CNN、RNN、Transformer，还有各种轻量级网络（MobileNet、TinyML）。AI算法在SOC上的落地，核心挑战是：怎么把大模型塞进小芯片。
我建议你记住一个原则：能量化就量化，能剪枝就剪枝，能蒸馏就蒸馏。INT8量化能把模型体积压缩4倍，推理速度提升2-3倍，精度损失通常不到1%。
3.2 算法复杂度分析：别光看大O
教科书上教我们看大O复杂度，但实际工程中，常数项往往比大O更致命。举个例子：
// 算法A：O(n)，但每次循环有3次乘法和2次访存
for (i = 0; i < n; i++) {
y[i] = a * x[i] + b * y[i-1]; // 3 mul + 2 load + 1 store
}
// 算法B：O(n²)，但每次循环只有1次加法
for (i = 0; i < n; i++) {
for (j = 0; j < n; j++) {
sum += x[i][j]; // 1 add + 1 load
}
}
当n很小的时候（比如n=10），算法B可能比算法A还快。为什么？因为算法A的访存开销太大了。我在项目中遇到过类似情况，当时用O(n²)的算法反而比O(n)的快，就是因为常数项和缓存命中率的差异。
所以，做复杂度分析时，我建议你关注三个维度：
- 计算复杂度：乘加次数、除法次数（除法很贵！）
- 访存复杂度：数据量、访问模式（连续还是随机？）
- 控制复杂度：分支预测、循环开销
3.3 资源评估：算力、内存、功耗
这是选型的硬约束。咱们一个一个拆。
3.3.1 算力评估
算力通常用GOPS（每秒十亿次操作）或GMACs（每秒十亿次乘加）来衡量。怎么估算？
举个例子：一个1D FIR滤波器，阶数为M，采样率为Fs。每秒需要的乘加次数 = M × Fs。如果M=128，Fs=48kHz，那么算力需求 = 128 × 48000 = 6.144 MMACs ≈ 0.006 GMACs。嗯，这点算力对现代SOC来说，毛毛雨。
但如果是AI推理呢？以MobileNetV2为例，一次推理大约需要3亿次乘加（300 MMACs）。如果要求30fps，那算力需求就是 300M × 30 = 9 GMACs。这就不是毛毛雨了，得用NPU或者DSP才能扛住。
注意：算力不是线性叠加的。多核并行时，要考虑通信开销和负载均衡。我曾经在一个项目里，4核DSP的理论算力是100 GOPS，实际跑出来只有60 GOPS，就是因为数据搬运占了40%的时间。
3.3.2 内存评估
内存分两块：程序存储和数据存储。
| 算法类型 | 程序存储（Flash） | 数据存储（SRAM/DRAM） | 典型值 |
|---|---|---|---|
| 信号处理（FFT） | 2-10 KB | N × 4 bytes（复数） | N=1024时，约8KB |
| 控制（PID） | 1-5 KB | 几十个变量 | 通常 < 1KB |
| AI推理（TinyML） | 模型权重：100KB-2MB | 中间特征图：50KB-1MB | 总内存约 200KB-3MB |
| AI推理（大模型） | 模型权重：10MB-100MB+ | 中间特征图：5MB-50MB | 需要外部DRAM |
我建议你留出30%的内存余量。为什么？因为调试阶段会加各种log、中间变量，还有中断栈、RTOS任务栈。我曾经因为内存算得太紧，导致系统在极端情况下栈溢出，查了三天才找到原因。
3.3.3 功耗评估
功耗是SOC设计的命门。算法选型对功耗的影响，比你想象的大得多。
一个简单的估算方法：
- 每MIPS（百万条指令）大约消耗 0.5-2 mW（取决于工艺和电压）
- 每MMACs大约消耗 0.1-0.5 mW（硬件加速器）
- 每MB的SRAM访问，大约消耗 10-50 mW
举个例子：一个语音唤醒算法，如果用DSP跑MFCC+GMM，功耗大约 5-10 mW。如果用CNN做端到端唤醒，功耗可能飙到 30-50 mW。但唤醒率可能从95%提升到98%。这3%的唤醒率提升，值不值那5倍的功耗？这就是选型时要权衡的。
我的经验：功耗评估一定要做最坏情况分析。比如AI推理，平时功耗可能只有20mW，但如果连续跑大模型，温度升高，漏电流增加，功耗可能翻倍。嗯，散热设计也得跟上。
3.4 技术选型报告：怎么写才专业？
报告是给老板和客户看的，也是给自己留底的。我写技术选型报告，通常包含以下5个部分：
- 需求回顾：一句话说清楚要解决什么问题
- 候选算法列表：至少2-3个方案，不能只有一个
- 评估矩阵：用表格对比各方案的性能、资源、功耗、开发难度
- 推荐方案：明确说选哪个，为什么
- 风险与缓解措施：比如“如果模型量化后精度下降，回退方案是...”
评估矩阵示例：
| 指标 | 方案A：传统信号处理 | 方案B：轻量AI | 方案C：全量AI |
|---|---|---|---|
| 准确率 | 92% | 96% | 98% |
| 算力需求 | 10 MMACs | 50 MMACs | 500 MMACs |
| 内存需求 | 16 KB | 128 KB | 2 MB |
| 功耗 | 3 mW | 15 mW | 80 mW |
| 开发周期 | 2周 | 6周 | 12周 |
| 推荐 | ✓ |
你看，方案B虽然准确率不是最高，但它在算力、内存、功耗和开发周期上取得了平衡。这就是选型的艺术——不是选最好的，而是选最合适的。
最后说一句：技术选型报告写完后，一定要做一次可行性验证。拿实际数据跑一遍，看看资源占用是不是和估算的一致。我见过太多报告写得天花乱坠，一跑就露馅的。嗯，纸上得来终觉浅，绝知此事要躬行。