第二章：软硬件划分的艺术——哪些代码该跑在CPU上，哪些该交给FPGA

做低延迟交易系统这么多年，我见过太多团队在软硬件划分上栽跟头。有人一股脑把所有逻辑塞进FPGA，结果开发周期拖了半年；有人死守CPU，眼睁睁看着微秒级的延迟被对手碾压。说白了，软硬件划分不是技术选择题，而是一道权衡的艺术题。

我个人习惯把这个问题拆成三个维度来看：延迟敏感度、逻辑复杂度、变更频率。这三个维度基本能帮你判断一段代码该待在哪边。

一、延迟敏感度：最直接的判断标准

先问自己一个问题：这段逻辑每多花1微秒，会不会亏钱？

如果答案是「会」，那它大概率该进FPGA。我举个例子，行情解析——从网口拿到原始数据包，到提取出买卖盘口，这个流程在CPU上跑大概要3-5微秒。但在FPGA里，同样的工作可以压到200纳秒以内。为什么？因为FPGA是流水线架构，数据包进来，解析、校验、提取字段，这些步骤可以同时进行。

那什么算「低敏感度」？比如风控检查中的一些非关键校验，或者日志记录。这些操作偶尔慢个几微秒，对交易结果没影响。我曾经见过一个团队，把日志打印逻辑也写进了FPGA，结果占用了大量LUT资源，得不偿失。

二、逻辑复杂度：FPGA不是万能药

FPGA擅长的是确定性、流水线化、并行度高的逻辑。但遇到复杂的状态机、大量的条件分支、或者需要动态内存分配的场景，FPGA就有点力不从心了。

举个例子，订单管理。一个订单从进入系统到成交，中间要经过价格检查、数量检查、账户余额检查、风控规则匹配……这些逻辑在CPU上写起来很自然，几十行C++代码就搞定了。但放到FPGA里，你得用状态机一个一个串起来，调试起来非常痛苦。

我记得有一次，客户非要把一个复杂的订单路由逻辑搬到FPGA上。逻辑本身不复杂，但涉及几十种路由策略的动态切换。我们折腾了两周，最后发现FPGA实现比CPU还慢——因为策略切换需要重新配置状态机，这个开销太大了。

三、变更频率：FPGA最怕改需求

FPGA的开发周期比CPU长得多。CPU上改一行代码，重新编译、部署，几分钟搞定。FPGA呢？综合、布局布线、生成比特流，少说半小时，多则几个小时。如果逻辑复杂，一次迭代可能要一整天。

所以，频繁变更的逻辑，留在CPU上。稳定的、几乎不改的逻辑，才适合放进FPGA。

我见过一个典型的反面案例：某交易团队把交易策略的参数配置逻辑写进了FPGA。结果策略团队每天要调整参数，每次都得重新烧录FPGA。后来他们加了一个CPU和FPGA之间的寄存器接口，参数通过CPU动态更新，这才解决了问题。

维度	适合CPU	适合FPGA
延迟敏感度	低（>10微秒可接受）	高（<1微秒要求）
逻辑复杂度	高（状态机、条件分支多）	低（流水线、并行计算）
变更频率	高（每天甚至每小时改）	低（几周甚至几个月改一次）

四、一个实际的划分案例

拿一个典型的低延迟交易系统来说，我通常这样划分：

• FPGA负责：行情解析、订单组帧、硬件时钟同步、低延迟网络协议栈（比如UDP offload）
• CPU负责：策略逻辑、风控规则、订单管理、日志记录、监控告警

中间层呢？用PCIe或AXI总线连接。FPGA把解析好的行情数据通过DMA直接写到CPU的内存里，CPU算完策略后，把订单指令通过寄存器写回FPGA，FPGA负责组帧发送。

这个架构的好处是：FPGA只做最核心的、延迟敏感的事，CPU处理复杂的、需要灵活变更的逻辑。两者各司其职，互不干扰。

五、软硬件划分的决策流程

下面这张图是我自己总结的决策流程，每次做新项目时我都会过一遍：

这个流程我用了好几年，基本没出过大错。你想想看，如果一段逻辑延迟敏感、逻辑简单、又几乎不改，那它简直就是为FPGA量身定做的。反过来，只要有一个条件不满足，强行塞进FPGA只会给自己找麻烦。

六、最后说两句

软硬件划分没有标准答案，每个系统都有自己的特点。但记住一个原则：FPGA做它擅长的，CPU做它擅长的，别让它们干不擅长的事。

嗯，这里要注意一点：划分不是一次性的。随着业务发展，你可能需要重新评估。比如某个逻辑一开始在CPU上跑得好好的，后来延迟要求变高了，那就得考虑迁移到FPGA。反过来，如果FPGA里的逻辑需要频繁调整，那就考虑挪回CPU。

灵活一点，别死守一个方案。这是我做了这么多年低延迟系统，最大的心得。

---