FPGA 和 NVIDIA Jetson 这类异构组合这几年在边缘智能、雷达通信、机器视觉领域越来越常见。我自己在客户现场被问得最多的问题是为什么非要在一块板卡上同时放 FPGA 和 GPU/AI 芯片一台高性能工控机跑软件不香吗等我真正做完基于 ZU19EG Jetson AGX Orin FMC 可扩展 AI 智能处理平台之后才体会到这种组合不是硬件厂商在堆料而是两种完全不同的计算模型在各自擅长的领域干活合在一起能把很多传统方案搞不定的活儿干得干净利落。这篇文章就围绕这套平台把我从选型、架构设计、硬件集成到软件联调的实际过程整理出来。主要面向三类人一是正在评估 FPGAAI 异构平台方案的工程师二是想用 FMC 扩展 IO 做数据采集和信号处理开发的人三是打算从 FPGA 单板卡转向异构智能处理平台、想了解软硬件分工和坑在哪里的同学。1. 异构板卡的核心价值FPGA 做前端的“肌肉记忆”Orin 做后端的“场景理解”先说一个宏观的判断纯 FPGA 可以直接做 CNN 推理但资源利用率很差而且开发效率低纯 Jetson AGX Orin 可以跑很重的神经网络但面对多通道 ADC 实时采集、自定义高速协议、相控阵时序控制这类任务无论是 CPU 还是 GPU 都很难做到微秒级确定性和逐比特级别的 IO 控制。所以这套平台的本质是“FPGA 在前端处理物理世界的原始信号Orin 在后端理解数据隐含的语义”。1.1 ZU19EG 在系统里到底扛下了什么ZU19EG 是 Zynq UltraScale MPSoC EG 系列里的高配型号。它的逻辑资源量、DSP 数量和高速收发器管脚都非常充裕可以用来做传统 FPGA 最擅长的事情。前端数据接入FMC 子卡上的高速 ADC、DAC、LVDS 相机、光纤模块信号进入 FPGA 后直接进 PL 侧的管脚不需要经过 CPU 中转。实时预处理滤波、数字下变频、FFT、脉冲压缩、图像 ROI 提取、像素格式转换这些计算在 PL 里做成流水线时钟周期级完成。协议硬解析比如 JESD204B、Aurora、自定义串行协议、相控阵波控时序FPGA 本身就是做协议状态机的天然场所。确定性控制给外部设备发同步脉冲、触发信号、相位控制字时延是确定的不会像 CPU 那样因为线程调度和中断发生抖动。ZU19EG 的 PS 侧还集成了四核 Cortex-A53 和双核 R5F可以跑裸机或者 Linux。实际工程里PS 一般不会去碰原始数据流而是用来做系统管理、寄存器配置、网络通信和启动引导。真正的高速数据通路全部放在 PL 侧通过 AXI/PCIe DMA 把数据交给 Orin。1.2 AGX Orin 在系统里的定位AGX Orin 是一块标准的 AI 计算模组拥有 Ampere 架构 GPU支持 TensorRT 加速。相对于上一代 AGX Xavier它的 AI 算力和 CPU 性能都提升明显。在这套板卡上Orin 通常承担如下工作跑检测/分类/分割模型比如 YOLO 系列、HRNet、各种 Transformer 结构运行多传感器融合算法把 FPGA 送过来的多路数据做时间同步和空间对齐做决策逻辑把推理结果转换成控制指令回传给 FPGA 或外部设备运行 Web 服务、MQTT/ZeroMQ 通信把处理结果上报到上层系统。Orin 上的 L4T/JetPack 生态很成熟基本可以当一台小服务器来用。Python/C 都支持部署 PyTorch 模型不算难事。真正需要注意的是Orin 的接口资源是固定的如果要接 FMC 子卡那样的高密度 IO它本身做不了必须依赖 FPGA 去接。1.3 两者协同的分界线我在设计这套平台时有一条非常明确的任务划分标准凡是需要“对每个时钟周期负责”的工作全部放 FPGA凡是需要“理解数据内涵”的工作全部放 Orin。这个原则基本不会出错。任务类型适合平台原因高速 ADC 数据采样和组帧FPGA时序确定性采样率可达 GSPS 级别数字滤波、DDC、FFTFPGA并行流水线吞吐高不占 AI 算力相控阵波控/脉冲时序FPGA微秒甚至纳秒级响应CPU/GPU 做不到目标识别、分类、跟踪OrinCNN/Transformer 在 GPU 上效率远高于 FPGA 逻辑多传感器融合和决策Orin算法生态丰富迭代快系统健康管理、远程升级两者配合PS 管配置PL 管数据Orin 管业务这套组合本质上把通信带宽和计算时延的“大头”在 FPGA 内部消化掉不把所有原始数据都暴力扔给 Orin。例如相控阵场景FPGA 只需要把波束合成后的少量 I/Q 数据送给 OrinOrin 做目标识别识别结果再通过 FPGA 的 GPIO 输出同步脉冲。整个数据量从几百 MB/s 降到几十 MB/s系统压力完全不同。2. FMC 接口的扩展价值插什么子卡这套平台就变成什么设备很多做软件出身的人第一次看到 FMC 接口会觉得这不过就是个高速连接器。实际上 FMCFPGA Mezzanine Card是 VITA 57.1 标准定义的一种子卡扩展接口它把 FPGA 的引脚资源、参考时钟和配置管理信号标准化了。FMC 接口的工程含义在于只要按标准设计载卡你可以随时更换不同功能的子卡让同一块板卡从“雷达信号采集板”变成“多路相机图像板”再变成“光通信接口板”。2.1 FMC 标准的几个关键点FMC 分为 LPC 和 HPC 两种规格。LPC 有 160 个引脚HPC 有 400 个引脚。工程上常用 HPC因为它提供的用户定义 IO 数量更多而且包含完整的差分时钟引脚对。FMC 连接器上除了用户 IO还定义了一组管理信号包括 I2C、JTAG、电源状态指示等。子卡上通常有一块 EEPROM里面存着子卡的厂商 ID、产品名、所需供电等信息载卡插上之后可以自动识别子卡。设计 FMC 子卡或者选型时我最关心三样东西用户 IO 数量和方向子卡带的是 LVDS 接口还是单端接口是否需要端接电阻参考时钟子卡上的 ADC/DAC 或 SerDes 通常需要一个高质量参考时钟这个时钟由载卡提供还是子卡自身产生供电能力HPC 接口能提供 3.3V、VADJ 等多种电源但总电流有限大功耗子卡必须有独立供电。FMC 接口还有一个很实用的好处它的引脚排列和 FPGA 封装 pin 之间存在天然的模块化关系。载卡设计时可以把一组 FMC 引脚对直接连到 FPGA 的高性能 HP/HR bank让同一个 bank 的引脚尽量归属同一组逻辑接口这样在 Vivado 里做引脚约束和时序收敛都更顺。2.2 载卡端 FMC 设计的实际考虑第一块载卡设计时我们犯过一个典型的错误为了布线方便把 FMC 的差分对随意拆散到不同的 FPGA bank。结果就是逻辑上很容易约束但高速信号跨 bank 导致部分引脚对无法直接使用硬件原语只能靠软件逻辑翻转工作频率大打折扣。之后我们定为一条原则FMC 上的一对差分信号必须连到 FPGA 同一个 bank 的相邻引脚对确保可以使用 IBUFDS/OBUFDS 原语和 ISERDESE3/OSERDESE3 这类高速收发组件。FMC 上的参考时钟引脚也不能随便连接。比如 ADC 子卡要求 M2C 时钟载卡到子卡通常在 FPGA 端用 MMCM/PLL 生成然后走差分时钟 buffer 给到子卡。这个时钟的 jitter 直接影响 ADC 采样性能。实测下来用 FPGA 内部 PLL 输出的时钟去驱动一片 250MSPS 的 ADC如果 PCB 走线等长没有处理好采样杂散会明显升高。2.3 适合这套平台的典型子卡组合这块板卡最常用的 FMC 子卡方案我试过几种高速采集组合FMC 上插一片 4 通道 250MSPS ADC 子卡FPGA 完成数据采集和数字下变频数据经 PCIe 送给 Orin 做频谱感知。这套方案特别适合无线电监测和通信信号识别。图像/相机组合FMC 接 Camera-Link 或 MIPI 转接子卡FPGA 做 Bayer 去马赛克、ROI 裁剪Orin 跑目标检测。比只靠 Orin 自带 MIPI 接口的方式更灵活可以接工业相机。光纤/高速接口组合FMC 子卡直接引出多路光纤收发器FPGA 内跑 Aurora/10G 以太网适合分布式阵列数据汇聚。相控阵波控组合FMC 子卡接移相器/衰减器控制板FPGA 根据 Orin 下发的波束指向角实时计算每个通道的相位码。这里 FMC 相当于一个高性能并行 IO 总线。FMC 的“可扩展”并不只是物理上能插不同子卡更重要的是 FPGA 内部的 IP 核和逻辑模块可以跟着子卡一起切换。比如一套代码里写好 JESD204B 接口模块换子卡时只需要调整参数和引脚约束不用重写整个工程。3. FPGA 的逻辑分工设计从数据搬运工到“第一道智能闸门”在很多人印象里FPGA 就是个数据搬运工把 ADC 数据搬到 DDR、再从 DDR 搬到 PCIe。但实际上 ZU19EG 能做的远不止搬运它的 DSP 资源可以完成不少实时算法把大量低层计算在数据进入 Orin 之前就解决掉。3.1 PL 侧的那些 IP 到底怎么排布我的做法是先把整条数据处理流水线划分为四个层级接口层、算法层、存储层、传输层。接口层对应 FMC 或板载高速连接器来的原始信号。如果是 JESD204B就需要例化 Xilinx JESD204B IP配好链路参数校准通过后再往上层送数据。如果接的是 LVDS 并行 ADC可以用 ISERDESE3 完成高速解串。算法层滤波器、DDC、FFT、模值计算、峰值检测等。这里尽量用 Xilinx FIR/FFT IP或者自己写简单的流水线逻辑。需要注意定点运算的位宽控制否则数据精度会在后续 AI 推理环节出问题。存储层数据要经过 DDR4 缓存还是直接流式通过取决于算法是否需要成帧处理。ZU19EG 的 PS 和 PL 各自都有 DDR 控制器的访问路径PL 侧可以挂独立的 DDR4 颗粒这样视频帧和 ADC 数据的缓存不会互相干扰。传输层PCIe DMA 或者 AXI 总线把处理后的结果送到 Orin。ZU19EG 的 PL 侧可以例化 Xilinx PCIe 硬核搭配 DMA 引擎把数据批量搬到上位机内存。这一层设计最容易出问题的地方是位宽和帧格式约定。比如我最初的工程里FPGA 送给 Orin 的数据是 32bit 对齐的复数 I/Q每一帧头带 16 字节时间戳。Orin 侧的接收程序必须严格按照帧协议解析不然一错位整个推理结果就乱套。硬件和软件两端对协议定义不清晰是异构项目最常见的沟通成本来源。3.2 PS 与 PL 的分工协作方式ZU19EG 的 PS 侧是完整的应用处理器系统跑 Linux 后可以做很多事情。我的工程里PS 主要做这些事上电时从 QSPI/eMMC 启动 Linux加载 PL 配置文件通过 AXI-Lite 寄存器配置 PL 里的模块参数比如滤波器系数、增益、触发模式管理外设以太网、UART、GPIO、看门狗和 Orin 通信除了高速 PCIe 数据通路PS 还提供一路千兆以太网作为带外管理通道。PL 侧则是纯粹的实时逻辑不跑操作系统。有时候会遇到一个问题PL 里的数据流需要和 PS 侧的状态交互比如 Orin 下发一个“开始采集”命令PS 写寄存器到 PLPL 里的逻辑检查到命令后立即启动 ADC 采样。这种跨时钟域交互需要做同步处理通常用两级触发器或握手信号解决。千万不要把单个控制信号直接跨时钟域打高否则极可能采集到亚稳态导致系统时好时坏。3.3 相控阵波控这类特殊场景的 FPGA 价值FMC 子卡如果接的是相控阵天线控制板那么 FPGA 的价值会被进一步放大。相控阵波束控制要求每个天线通道的移相器在极短时间内同时更新相位码这个任务如果交给 CPU每次操作要通过总线写几百个寄存器时延和确定性都无法保证而 FPGA 则可以通过一条“触发总线”同时更新所有通道。具体到实现PL 里维护一张相位码查找表行索引对应波束指向角列对应通道号。Orin 只是把目标角度写到一个配置寄存器FPGA 内部自动查表并在外部同步脉冲的边沿统一锁存输出。从 Orin 下发角度到所有移相器实际更新完毕整个链路可以做到微秒级。这个“软件定义参数、硬件保证执行时延”的模式我认为是异构平台的精髓。4. AGX Orin 上的软件链路从镜像烧写到 AI 推理管线Orin 本身支持标准的 JetPack SDK软件栈相对成熟。这一部分我不打算重复官方文档的内容主要讲在异构板卡上最容易踩的工程细节。4.1 系统环境和 PCIe 驱动准备首先Orin 模组需要烧写 L4TLinux for Tegra系统镜像。烧写方式可以通过 SDK Manager也可以直接用命令行向模组烧录。因为板卡电源、时钟和复位电路都是定制的所以必须确认模组的载板配置和 P3737 默认开发板是否一致避免 PCIe 和 USB 等接口因为配置不匹配而无法正常工作。Orin 和 FPGA 之间的 PCIe 链路是这套平台效率的关键。我习惯让 Orin 作为 RCRoot ComplexFPGA 作为 EPEndpoint。这样 Orin 上电后会自动枚举到 FPGA 的 PCIe 设备无需外部主机参与。FPGA 端使用 Xilinx XDMA 或自研 DMA 逻辑只需在 Orin 侧为 PCIe 设备加载驱动。使用 Xilinx 官方驱动时dma 缓冲区默认是内核空间需要实现 mmap 接口把 DMA 缓冲区映射到用户空间。简单的做法是在应用层通过mmap映射/dev/xdma0_c2h_0然后订阅 poll 事件等待数据到达。4.2 推理管线的性能优化AI 推理部分的工程化关键在于 TensorRT 的使用。我的经验是先在 PC 上用 PyTorch 训练和验证模型导出 ONNX再到 Orin 上用 TensorRT 转成 engine 文件。转换时重点关注三件事输入尺寸固定动态尺寸虽然灵活但性能不如静态尺寸边缘场景尽量固定输入分辨率。精度选择推荐先用 FP16如果模型对量化敏感再退回到 BF16/FP32。INT8 能获得最高性能但需要标定数据集过拟合风险也存在。显存复用Orin 的显存和内存共享如果数据预处理和推理分开了大块内存很容易出现显存不足。最好用 GPU 上的 buffer pool避免频繁 allocation。模型的“精度-速度”平衡我一般不会只盯着 mAP还要看单帧推理时延和端到端时延。实战里YOLOv8s 在 AGX Orin 上跑 FP16 可以达到相当不错的吞吐但具体帧率取决于输入分辨率和 batch 配置。比较推荐的做法是一次推理一个 batch因为边缘侧数据是流式到达batch 太大反而增加延时。4.3 FPGA 与 Orin 的数据流应用层设计总线上的数据要进入 AI 管线中间还需要一个应用层适配。我的工程里一般维护一个环形缓冲FPGA 通过 DMA 写进来的数据先进入队列Orin 侧的处理线程从队列取数据解析帧格式后送入 GPU 显存做预处理。这里有一个性能坑DMA 中断频率过高会导致 CPU 占用飙升。如果 FPGA 每来一小包数据就触发一次中断Orin 的 12 核 CPU 都会被中断处理占满根本没时间跑模型。解决办法是中断聚合FPGA 侧把数据累积到一定字节数再产生一次 DMA 中断或者 Orin 侧的驱动采用 NAPI 式的轮询与中断结合机制。实测调整后是把中断频率从原来的每秒几万次降到了每秒几百次推理帧率才真正起来。代码层面有一个小示例可参考import mmap import numpy as np # 假设已经加载 xdma 驱动并映射 DMA 缓冲区 with open(/dev/xdma0_c2h_0, rb) as f: mm mmap.mmap(f.fileno(), length0x1000000, offset0) while True: # 等待数据可用实际工程用 select/poll data mm.read(4096) # 解析帧头放入 GPU buffer交给 TensorRT 推理这类代码虽短但足够说明整个用户态数据流的工作方式驱动负责搬运应用层负责帧解析和显存投喂。5. 硬件集成和整板调试中最容易翻车的五个点这块板卡不是简单的“FPGA 板 Orin 模组”拼在一起而是两个高功耗、高速信号密集的系统级器件共存。在整机联调过程中以下五个问题是我认为最值得写在这里分享的因为它们很难从芯片手册里直接查到答案。5.1 供电时序和功耗预算ZU19EG 需要多路电源包括 VCCINT、VCCBRAM、VCCAUX、VCCO 等每一路都有上电顺序要求。AGX Orin 模组则有更严格的电源时序它的 5V/12V 主供电需要先稳定之后模组内部 PMIC 按顺序拉起来还要响应模组发出的复位电平。如果整板的电源管理逻辑在时序上处理不好非常容易出现“单独测 FPGA 正常、单独测 Orin 正常、联合上电却起不来”的现象。解决办法是使用具备时序控制的电源管理方案。复杂板卡上用 FPGA 的 GPIO 配合外部电源监控芯片去控制每一路的 enable 信号并设置上电延迟有条件的话加一个电源时序分析仪用示波器探针同时观察多路电源的爬升曲线。另外一个容易被低估的是功耗预算。一块满负载的 ZU19EG 加上一块重载 Orin 模组峰值功耗远超普通工控机或单板机。项目里功耗预算建议至少按照 1.5 倍计算整机电源要留出足够余量电源模组自身的散热也不能忽视。5.2 时钟树设计FPGA 和 Orin 都有各自的高速时钟域。FPGA 的 GT 时钟、FMC 接口的 M2C 参考时钟、JESD204B 的器件时钟三者必须来自一个设计好的时钟树。尤其 JESD204B 链路子卡的 ADC 器件时钟和 FPGA 逻辑参考时钟必须同源或者具有明确的相位关系否则链路难以锁定。我在实际调试时遇到过 JESD204B 偶发性失锁的问题排查到最后发现是 FMC 子卡参考时钟从 FPGA PLL 输出后走过一段较长走线导致时钟抖动偏大。后来改用载板上独立的高性能时钟芯片为 FMC 接口提供 M2C 时钟问题彻底解决。这个调整也再次印证了 FMC 时钟质量的优先级高于布线便利性。5.3 高速信号布线中的引脚拓扑FMC 连接器到 FPGA 之间的高速差分走线需要严格控制等长和阻抗。HPC 连接器有几百个引脚如果仿真不充分盲目的 via 切换会造成明显的插入损耗。经验做法是高速差分对优先走内层带状线避免跨分割参考地平面要连续换层过孔旁边要加足够的地过孔。这个细节直接决定了能不能跑满协议的最高速率。对于 GT 时钟对建议单独包地处理并且远离其他高速信号防止串扰。用 Vivado 的 Xilinx 约束工具也可以把走线等长要求输出给 PCB 设计工具这样可以减少因为手工改线产生的错误。5.4 散热与结构Orin 模组的载板设计包含散热接口机箱必须配合导热垫和风扇。ZU19EG 的功耗同样不可小看也必须有专门的散热器。两块高功耗芯片摆在同一块板卡上热设计的核心是确保热量能单向导出机箱不能在板内形成“热循环”。调试阶段我习惯在软件里读 Orin 的 CPU/GPU 温度以及 FPGA 的 die 温度通过日志持续监测。高温不仅导致降频更会让 FPGA 的逻辑时序裕量变小出现非常“奇葩”的偶发错误。先解决热再解决信号完整性这一点在异构板卡上尤其重要。5.5 调试手段的优先级异构板卡的功能复杂出现问题时要从“链路分层”的角度排查。我一般按照“电源→时钟→复位→低速控制→高速数据→AI 效果”的顺序逐层确认。调试高速链路最有效的手段是FPGA 内部用 ILA/System ILA 抓数据PCIe 链路用 lspci / dmesg 确认枚举是否正常Orin 侧先写一个最简单的回环测试程序让 FPGA 向 Orin 发固定数确认链路后再跑真实数据。千万别一开始就调 AI 模型。先保证数据通路全通、数据内容正确再去调模型精度和推理速度。6. 从原型实测到产品化落地的一点体会最后这部分不是标准教程而是我把这套平台实际放到项目里运行一段时间后的总结。数据通路全打通之后最让我印象深刻的是这块板卡处理“高速采集 智能识别”这类任务时展现出的系统级优势。6.1 一组有代表性的链路实测数据我们在实验室的调试条件大概是这样FMC 子卡接入一套 4 通道 250MSPS 数据采集FPGA 内部完成数字下变频、滤波和 FFT通过 PCIe Gen3 x4 链路把频谱数据打包给 AGX OrinOrin 运行一个针对特定信号特征的检测模型。最终端到端的数据时延从采集到检测结果输出能够稳定控制在亚毫秒到毫秒级区间。相比之前的“高速采集卡 上位机 GPU 服务器”方案这个平台的体积、功耗和时延都有了数量级上的改善。当然反馈也提到这套平台并不是没有短板。比如在批量阶段整板成本相对较高器件采购周期长而且 FPGA 逻辑工程师和 AI 算法工程师必须紧密配合团队协作复杂度比纯软件方案高。如果项目里既没有 FPGA 硬件经验也没有边缘部署经验我不建议一上来就做这种全定制板卡。6.2 从 FPGA 到 Orin 的协同优化软件和硬件协同优化往往比单点调优带来的收益更大。我最后做的一件事就是把 FPGA 送给 Orin 的数据格式从固定的 32bit 整形改为 16bit 定点数据量直接减半Orin 侧的 TensorRT 输入预处理里也少了一次转换操作。仅仅这一个改动端到端吞吐提升了约一倍。类似的优化点还有放大器精度、DMA burst 长度、CPU 绑定核几乎每项都能带来惊喜。真正到了跑现场稳定性的阶段我发现这类板卡最容易暴露问题的还是那些“不起眼”的细节比如 FMC 连接器的接触可靠性、PCIe 热插拔时的链路恢复、长时间运行后温度导致的时序漂移。这些都是文档里很少写、但项目真正要做成产品时不能忽略的部分。6.3 我的最终建议如果你是第一次做 FPGAOrinFMC 平台我认为正确的路线是先使用现成的 FMC 载板和评估套件跑通最小功能原型把 JESD204B、PCIe DMA、TensorRT 推理这条完整链路走通再考虑定制板卡。千万不要一上来就画板子。异构平台的价值在于合理的任务分配 稳定的数据链路 精细的软硬件协同这三件事没办法靠堆资料解决只能通过一轮轮调试和现场验证来积累。我也建议团队里至少要有一个人能同时看懂 FPGA 逻辑和 Orin 侧代码否则每次软硬件冲突都可能是漫长扯皮。等这条链路真正稳定运行你就能体会到FPGA 把原始信号变成“可理解的数据”Orin 把数据变成“可执行的决策”而 FMC 则让这套平台可以随场景变化自由换接口——这套组合真的可以一套硬件应对多种智能感知场景。