第三章 软硬件划分：划分的目标与原则

好，咱们进入正题。软硬件划分，说白了就是决定哪部分功能用硬件实现，哪部分用软件跑。这步棋走对了，整个项目就顺了。走错了？嗯，后面全是坑。

我见过太多团队，一上来就拍脑袋说“这个模块必须硬件加速”，结果流片回来发现性能过剩，成本却翻了一倍。也见过反过来的——软件跑得慢如蜗牛，最后只能砍功能。所以，划分这事，真得认真对待。

3.1 划分的目标

划分的目标其实就三个：性能、功耗、成本。但你别指望三个都做到最好，那是做梦。实际项目中，我们都是在做权衡。

• 性能目标：把计算密集、延迟敏感的部分扔给硬件。比如视频编解码、加密算法。
• 功耗目标：硬件虽然快，但面积大、漏电多。软件灵活，但跑起来费电。得算总账。
• 成本目标：硬件改动一次几百万，软件改一行就行。所以，不确定的功能，先放软件。

我个人习惯，在项目初期先画一个“性能-灵活性”矩阵。横轴是灵活性需求，纵轴是性能要求。右上角的模块，基本就是硬件的候选者。

3.2 划分的原则

原则这东西，听起来虚，但真能救命。我总结了几条，都是血泪换来的。

1. 数据流主导原则：数据流清晰、处理方式固定的模块，适合硬件。控制流复杂、分支多的，留给软件。
2. 通信最小化原则：硬件和软件之间通信越少越好。每次跨边界传输数据，都有延迟和功耗开销。
3. 重用性原则：如果某个功能在多个场景下都要用，做成硬件IP更划算。
4. 确定性原则：对实时性要求苛刻的（比如刹车控制），必须硬件实现。软件调度有不确定性。

3.3 划分方法

方法有很多，我挑三种最常用的讲。你根据项目规模选就行。

3.3.1 基于图的方法

把系统建模成一张图。节点是功能模块，边是数据依赖或通信量。然后在这个图上做切割。

常用的算法有：

• Kernighan-Lin算法：经典的图分割算法，把图切成两部分，让跨部分的边权重最小。
• 谱聚类：用拉普拉斯矩阵的特征向量做聚类，适合大规模系统。

举个例子，假设我们有5个任务，它们之间的通信量如下：

任务	A	B	C	D	E
A	-	10	2	0	1
B	10	-	8	3	0
C	2	8	-	9	4
D	0	3	9	-	7
E	1	0	4	7	-

用KL算法跑一遍，很可能把{A, B}分到硬件，{C, D, E}分到软件。因为A和B之间通信量最大，放一起能减少跨边界开销。

3.3.2 基于启发式的方法

启发式，说白了就是“经验+规则”。没有最优解，但能在合理时间内找到“够好”的解。

常见的启发式包括：

• 模拟退火：先随机划分，然后不断扰动，接受更优解，偶尔接受差解（为了跳出局部最优）。
• 遗传算法：把划分方案编码成染色体，通过交叉、变异、选择来进化。
• 贪心算法：每次选一个收益最大的模块移到硬件，直到满足约束。

我记得有个项目，系统有200多个功能模块。用图方法算了一整天没出结果。后来换遗传算法，跑了20分钟就给出了一个不错的方案。虽然比最优解差了5%，但时间省了太多。

// 伪代码：贪心划分
while (硬件面积 < 面积上限) {
    best_module = null;
    best_gain = -INF;
    for (每个还在软件中的模块 m) {
        gain = 性能提升(m) - 面积代价(m);
        if (gain > best_gain) {
            best_gain = gain;
            best_module = m;
        }
    }
    把 best_module 移到硬件;
}

3.3.3 基于机器学习的方法

这是最近几年的新方向。用历史项目的划分数据训练一个模型，然后对新项目做预测。

常用模型：

• 决策树/随机森林：可解释性强，能告诉你为什么某个模块被分到硬件。
• 图神经网络（GNN）：天然适合处理任务依赖图，效果最好。
• 强化学习：把划分过程建模成马尔可夫决策过程，让智能体自己学策略。

不过我得泼点冷水。机器学习方法需要大量标注数据。你想想看，一个公司能有多少个完整的SoC项目？几十个顶天了。数据量不够，模型容易过拟合。我目前只在大型芯片公司见过落地案例，小团队还是老老实实用启发式吧。

3.4 划分的评估指标

划分得好不好，不能光凭感觉。得有量化指标。我常用的有这几个：

指标	公式/说明	我的经验阈值
加速比	纯软件执行时间 / 软硬件协同执行时间	大于2倍才算有意义
硬件利用率	硬件实际工作时间 / 总时间	低于30%说明硬件浪费了
通信开销比	跨边界通信时间 / 总执行时间	超过20%就要重新考虑划分
面积效率	性能提升百分比 / 面积增加百分比	小于1说明不划算

另外，我建议你做一个帕累托曲线。横轴是面积/功耗，纵轴是性能。把不同划分方案的点画上去，选那些在“前沿”上的方案。那些被完全支配的点（面积更大、性能更差），直接扔掉。

你看这张图，红色连线上的点就是帕累托前沿。选哪个？看你的项目约束。如果面积预算紧张，就选左边的点。如果性能优先，就选上边的点。没有绝对的好坏，只有合不合适的方案。