软硬件划分方法论：从任务分析到接口评估
做5G调制解调器设计，最头疼的问题是什么？
我个人觉得，不是算法有多复杂，也不是工艺有多先进。而是——哪些功能用硬件做，哪些用软件跑。这个决策一旦错了，后面改起来，成本高得吓人。
我在一个LTE项目上就吃过这个亏。当时团队拍脑袋把信道估计全扔给了DSP，结果吞吐率死活上不去。后来一分析，其实一半的计算可以用硬件加速器搞定。嗯，那次教训让我养成了一个习惯：先算清楚，再动手。
这一章，我就把软硬件划分的实战方法论掰开揉碎讲给你听。
任务分析与吞吐率计算
软硬件划分的第一步，不是画架构图，而是算账。
你得先搞清楚：每个任务到底要处理多少数据？每秒要完成多少次操作？
举个例子，5G NR的PDSCH（物理下行共享信道）处理。一个典型的流程包括：
- 解资源映射
- 信道估计
- MIMO检测
- 解调
- 解速率匹配
- LDPC解码
每个子任务，我们都要算它的吞吐率需求。
吞吐率计算公式：
Throughput = 数据块大小 × 每秒处理的块数
或者更细粒度：
Throughput = 采样率 × 每个采样点的操作数
我习惯先列一个表格，把每个任务的参数填进去：
| 任务 | 数据率 (Mbps) | 每比特操作数 | 总计算量 (GOPS) |
|---|---|---|---|
| 信道估计 | 2457.6 | 8 | 19.66 |
| MIMO检测 | 2457.6 | 32 | 78.64 |
| LDPC解码 | 983.0 | 64 | 62.91 |
看到这个表，你可能会问：为什么LDPC解码的数据率反而低？
因为解码是在速率匹配之后，数据已经被压缩了。但它的每比特操作数很高，因为迭代解码需要反复计算。
关键点来了：总计算量超过100 GOPS的任务，用纯软件跑？想都别想。ARM Cortex-A系列，一个核也就几个GOPS。你算算需要多少个核？
我的经验：
当单个任务的计算量超过5 GOPS时，就要认真考虑硬件加速了。超过20 GOPS，基本可以确定必须上硬件。
延迟约束与实时性
吞吐率算完了，接下来看延迟。
5G对延迟的要求有多苛刻？我给你几个数字：
- eMBB（增强移动宽带）：用户面延迟 < 4ms
- URLLC（超可靠低延迟）：用户面延迟 < 1ms
- 控制面延迟：从空闲到激活 < 10ms
你想想看，一个LDPC解码器，如果软件实现需要2ms，那整个链路预算就炸了。
我曾经在一个项目中，把Turbo解码器放在DSP上跑。仿真时一切正常，但一上板子，延迟超标30%。查了半天，发现是DSP的cache miss导致解码时间抖动太大。嗯，从那以后，我对延迟的确定性特别敏感。
延迟分析要关注三个维度：
- 绝对延迟：从输入到输出的总时间
- 延迟抖动：最大延迟和最小延迟的差值
- 延迟分布：不同场景下的延迟表现
注意：
软件实现的延迟抖动通常比硬件大一个数量级。对于URLLC场景，硬件加速几乎是唯一选择。
怎么判断一个任务对延迟敏感？我有个简单方法：看它是否在关键路径上。比如HARQ（混合自动重传请求）的反馈，必须在3个OFDM符号内完成。这种任务，软件很难满足。
硬件加速器识别
好了，现在我们知道哪些任务计算量大、延迟要求高。下一步就是识别哪些适合做成硬件加速器。
我总结了三个判断标准：
- 计算密集：每数据样本的操作数 > 10
- 数据流规则：处理模式固定，没有太多分支
- 重复性高：同样的操作要执行成千上万次
在5G调制解调器中，典型的硬件加速器候选包括：
| 加速器 | 原因 | 我见过的坑 |
|---|---|---|
| FFT/IFFT | 计算密集，数据流规则 | 曾经把FFT大小写死在代码里，后来NR支持多种子载波间隔，改得想哭 |
| LDPC解码器 | 迭代计算，延迟敏感 | 早期版本没考虑多码块并行，吞吐率上不去 |
| 信道估计器 | 矩阵运算多，实时性要求高 | DMRS图案变了，硬件得重新综合 |
| MIMO检测器 | 复杂度随天线数指数增长 | ML检测太耗资源，最后用了MMSE |
但也不是所有计算密集的任务都适合硬件。举个例子，调度器。它虽然计算量大，但算法经常变，而且有很多条件分支。这种任务，我建议留在软件里。
一个实用的判断方法：
如果一个算法在3年内可能被替换，就别做成硬件。否则，流片回来发现算法过时了，那才叫欲哭无泪。
接口带宽评估
硬件加速器识别出来了，但还有一个关键问题：数据怎么喂给它？
接口带宽评估，说白了就是算算数据通路能不能撑住。
我见过一个案例：团队设计了一个很牛的LDPC加速器，解码吞吐率能做到20 Gbps。结果呢？DDR带宽只有25.6 GB/s，但加速器需要从DDR读码字、写软比特，再加上其他模块抢带宽，实际可用带宽不到10 GB/s。瓶颈不在加速器，在接口。
接口带宽评估要算三笔账：
- 读带宽：从内存或前级模块读取输入数据
- 写带宽：把处理结果写回内存或传给后级模块
- 控制带宽：配置寄存器、状态反馈等
举个例子，一个MIMO检测器，4天线，256QAM调制：
- 输入：每个符号4个天线 × 8比特（I/Q各4比特）= 32比特
- 采样率：30.72 MHz（20 MHz带宽）
- 读带宽：32 × 30.72 = 983.04 Mbps
- 输出：软比特，每个比特8比特LLR，共4层 × 8比特 = 32比特
- 写带宽：32 × 30.72 = 983.04 Mbps
总接口带宽约2 Gbps。如果使用AXI总线，一个128位宽、200 MHz的接口，理论带宽是25.6 Gbps。看起来绰绰有余？
别急，还有协议开销。AXI的读写事务有地址阶段、数据阶段、响应阶段。实际有效带宽通常只有理论值的60%-70%。再加上其他模块共享总线，你得留出50%的余量。
我的建议：
接口带宽评估时，把理论值打五折。如果还够用，那就放心了。如果不够，要么加宽总线，要么用专用点对点接口。
还有一个容易被忽略的点：接口延迟。有些加速器对数据到达时间有严格要求。比如FFT，数据必须连续输入，中间不能有气泡。如果总线被其他模块占用，数据断流了，FFT就得等，整个流水线就卡住了。
我曾经在AXI总线上加了一个FIFO，专门给FFT做数据缓冲。虽然增加了面积，但保证了数据流的连续性。嗯，有时候，面积换性能是值得的。
软硬件划分的决策流程
说了这么多，我总结一下软硬件划分的完整流程。下面这张图是我自己画的，你可以参考：
这个流程看起来简单，但每个步骤都有很多细节。我建议你从任务分解开始，把整个物理层处理链路画出来。然后逐个任务做吞吐率和延迟分析。最后，用接口带宽评估来验证你的划分是否可行。
记住：
软硬件划分不是一次性的工作。随着算法演进和工艺进步，划分边界会变化。我每半年会重新审视一次划分方案，看看有没有新的优化空间。
好了，这一章的内容就到这里。软硬件划分是调制解调器设计的核心决策，直接影响芯片的性能、功耗和面积。希望我的这些实战经验能帮你少走弯路。