低延迟FPGA加速卡选型与开发流程：RTL还是HLS，In-line还是Look-aside
时间: 2026-10-23
决定上 FPGA 的低延迟交易团队，真正的难题从第二天才开始。
“要不要用 FPGA”是个战略问题，答案通常很清晰——软件方案内核旁路做到极致，延迟也在三五微秒的量级，而 FPGA 硬件加速 能把 tick-to-trade 压到纳秒级。但接下来的三个问题才是工程的开始：买哪张卡？用 RTL 还是 HLS 开发？走 In-line 还是 Look-aside 架构？这三个决策互相咬合，选错任何一个，轻则返工半年，重则整套架构推倒重来。
这篇文章把三个决策逐个拆开，讲清楚各自的取舍逻辑。
先选卡：加速卡的关键指标不是算力
通用加速卡的宣传页爱讲算力，低延迟交易卡的选型逻辑完全不同。核心指标有四项。
收发器延迟是第一指标。 数据进出芯片都要过收发器，这一段往往占整条 tick-to-trade 链路延迟的大头。AMD 专为电子交易设计的 Alveo UL3524/UL3422 系列采用新一代 GTF 收发器，存取延迟约 2.34 纳秒，而上一代 GTY 收发器需要约 16 纳秒——单是收发器一代之差就是 7 倍。在公开的 STAC-T0 基准测试（业界公认的 tick-to-trade 网络 I/O 延迟评测）中，目前最快成绩是用 Alveo UL3524 跑出的 13.9 纳秒可执行延迟，抖动压到约 200 皮秒。选卡时先看收发器代际，再看别的。
端口密度与外形尺寸决定部署形态。 同样芯片的 UL3524 提供 32 个以太网口，适合一层交叉连接等高端口密度场景；UL3422 把端口减半、做成全高半长的短卡，为的是塞进更多型号的托管机房服务器。托管机柜按U位计费，卡的形态直接折算成成本。
片上内存与接口代数。 需要本地缓存订单簿或行情快照的设计，要确认板载内存的类型和容量；PCIe 代数则影响与主机交互的带宽和延迟。
开发生态。 Vivado/Vitis 工具链、参考设计、商业 IP 核（协议解析、订单簿、TCP/UDP 卸载）的丰富程度，决定团队有多少东西需要自己从零造。生态成熟的平台，能把开发周期砍掉一大半。
RTL 还是 HLS：确定性与开发速度的交换
卡选定之后，第二个决策是用什么方式写逻辑。
RTL（寄存器传输级，Verilog/VHDL） 是传统路线：开发者直接描述每个时钟周期里硬件做什么，对电路有周期级的完全控制。好处是延迟可以做到理论极限且完全确定——每一拍的行为都在设计者手里。代价是开发慢、调试难、人才稀缺。一个熟练的 RTL 工程师的培养周期以年计。
HLS（高层次综合） 用 C/C++ 描述算法，工具自动综合成硬件电路。开发效率数倍于 RTL，策略人员熟悉的代码可以直接进硬件，迭代速度完全不同。代价是生成的电路在延迟和资源效率上通常不如手工 RTL，且综合工具的行为引入了额外的不确定性——对每一拍都要精确控制的关键路径，HLS 的输出往往还需要人工介入优化。
实务中的答案很少是二选一，而是按路径分层：数据路径（行情解码、报单组装、协议处理）用 RTL 打磨到极限，这段逻辑相对固定、对延迟最敏感；策略层和复杂触发逻辑可以用 HLS，换取迭代速度——商业方案里甚至有专门用 HLS 开放自定义触发器的做法，让客户在不动数据路径的前提下快速部署自有策略。团队的工程师构成，往往比技术偏好更能决定这条路线的比例分配。
In-line 还是 Look-aside：FPGA 站在哪里
这是架构层面最关键的一个决策：FPGA 在数据流里的位置。
In-line（线上串联，也叫 bump-in-the-wire）：FPGA 直接串在网络链路上，行情数据进卡、订单从卡出，全部流量物理上必须经过 FPGA。这是延迟最低的姿态——数据不用绕道主机，tick-to-trade 路径可以完全在硬件内闭合。行情解码、订单簿维护、事前风控闸门、订单触发这类对延迟极度敏感的功能，放在 In-line 位置才有意义。事前风控尤其典型：纳秒级速度下做有限的实时检查，超阈值直接在硬件里拦单，这是软件风控做不到的事。
Look-aside（旁路协处理）：FPGA 通过 PCIe 挂在主机旁边，CPU 把计算任务 offload 过来。延迟比 In-line 高一个量级——仅 FPGA 到主机的往返就要几百纳秒——但灵活性好得多：复杂策略、大状态计算、需要频繁变更的逻辑，放在这里比纯 In-line 更容易实现和维护。
越来越多的实盘系统是混合架构：In-line 位置放行情的预处理和过滤——以线速完成解码、抽取关键字段、重建订单簿，再把处理好的数据交给主机或另一张卡跑策略。数据路径硬件化、策略迭代软件化，各取所长。行业里甚至有专门的线路仲裁设计：用 FPGA 合并微波和光纤两路行情，在硬件里完成微小时间偏移下的可靠源选择——这类活儿只有 In-line 位置干得了。
选择依据很直白：延迟预算在百纳秒级、逻辑相对固定的功能走 In-line；需要频繁迭代、逻辑复杂的功能走 Look-aside 或留在主机；两者之间用清晰的数据接口划界。
开发流程：FPGA 独有的几个坑
低延迟 FPGA 项目的开发流程，大致是需求拆解、数据/控制路径划分、协议与 IP 选型、仿真验证、时序收敛、灰度上线六步。其中两步是 FPGA 特有的。
仿真验证要比软件项目重得多。 硬件没有 try-catch，一个边界条件的疏忽就是实盘事故。交易所协议的状态机要用真实行情回放逐字节验证，极端场景——洪峰、乱序、断线重连——必须全覆盖。仿真环境的投入通常占项目总工时的一半以上，这部分省不得。
时序收敛是 FPGA 独有的关卡。 逻辑写对不等于跑得动：设计必须让所有信号在一个时钟周期内走完该走的路。频率往上拉一点，布线资源紧张一点，时序就可能不收敛，然后是漫长的重构迭代。低延迟设计为了把流水级数压到最少，往往主动牺牲频率换延迟，这个平衡需要在架构设计时就定下来，而不是综合报错之后再回头改。
灰度上线阶段建议用并行双跑：新硬件链路和旧系统同时处理真实行情，逐条比对输出，跑满至少几个完整交易周再切流量。
选型决策树：三个问题定架构
把全文收成三个问题：
延迟预算是多少？ 微秒级可以接受，内核旁路软件方案就够用，先别碰 FPGA；亚微秒级，FPGA + Look-aside；纳秒级必争，In-line 是唯一的门。
团队是什么构成？ 有成熟 RTL 团队，数据路径自研到底；以软件工程师为主，选生态成熟、IP 核丰富的平台，HLS 补策略层。
逻辑变更频率多高？ 协议解码、风控闸门这类稳定逻辑值得 RTL 精修；策略和触发逻辑月月都在变，留给 HLS 或主机侧。
写在最后
FPGA 选型没有标准答案，但有一条主线：所有决策都要回到“确定性”三个字。收发器代际、开发语言、架构位置，每一个选择都是在用灵活性或成本交换延迟的确定性。
这也是盛立科技做产品的底层逻辑。REM 柜台和 EFH 行情都采用工业级 FPGA 芯片，把行情解码、事前风控这类数据路径逻辑沉到硬件里，换取微秒级以下的确定性表现；面向证券、期货市场的完整解决方案，从柜台到行情再到网络链路，按同一套确定性哲学组织。盛立科技在这个方向上走了近二十年，早年与华为的合作项目曾入围科技部重点研发专项，2026 年又先后与智臾科技（DolphinDB）达成战略合作、获香港交易所两项年度大奖。选型问题没有标准答案，但踩过的坑会留下答案。
常见问题
Q1：低延迟交易为什么用 FPGA 而不用软件方案？
软件方案即使做内核旁路，延迟也在3-5微秒量级且抖动大；FPGA 用硬件流水线处理，tick-to-trade 可压到纳秒级且行为完全确定。目前公开的 STAC-T0 基准最快成绩为 13.9 纳秒，由 FPGA 加速卡实现。
Q2：FPGA 加速卡选型最该看什么指标？
四项：收发器代际（新一代 GTF 收发器延迟约 2.34 纳秒，是 tick-to-trade 链路的大头）、端口密度与板卡形态（影响托管机房部署）、片上内存与 PCIe 代数、以及工具链和商业 IP 核生态的成熟度。
Q3：RTL 和 HLS 开发路线怎么选？
按路径分层：行情解码、报单组装等数据路径逻辑固定且延迟敏感，用 RTL 打磨到周期级最优；策略层和复杂触发逻辑迭代频繁，可用 HLS 以 C/C++ 快速开发。团队工程师构成往往比技术偏好更决定路线比例。
Q4：In-line 和 Look-aside 架构有什么区别？
In-line 是 FPGA 串在网络链路上，所有流量物理过卡，延迟最低，适合行情解码、事前风控、订单触发；Look-aside 是 FPGA 通过 PCIe 作为主机协处理器，延迟高几百纳秒但灵活，适合复杂策略计算。实盘系统多采用两者混合。
Q5：事前风控为什么适合放在 FPGA 上做？
事前风控需要以纳秒级速度对每笔委托做验资验仓和限额检查，软件风控的延迟无法满足。FPGA 以 In-line 方式串联在报单链路中，超阈值委托直接在硬件层拦截，既满足监管的事前风控要求，又不显著增加交易延迟。
