我砍掉了 FPGA 里的 ARM 核，项目反而提前交付了
一个 UDP IP 核，省掉 ARM 程序员，省掉 Linux 软件栈------项目不仅没延期，还提前交付了。
先说一个真实的故事
笔者做过一个多通道数据采集项目：8 路 ADC、DDR3 缓存、千兆以太网回传、上位机波形显示。
需求摆出来的时候，团队里自然有人提议：
"用 Zynq 啊！ARM 核跑 Linux，FPGA 端做采集，现成的方案。"
听起来很美好。但仔细一算账，问题来了------
| 项目 | SoC FPGA 方案 (ARM + FPGA) | 纯 FPGA + 网口方案 |
|---|---|---|
| 芯片成本 | Zynq 7020 ≈ ¥150-300 | 安路 PH1 FPGA ≈ ¥30-60 |
| 外围成本 | DDR3 + Flash + 电源管理更复杂 | 同规格 DDR3，无需 Boot 系统 |
| BOM 总成本 | ≈ ¥400-600 | ≈ ¥150-250 |
| 开发团队 | FPGA 工程师 + ARM/Linux 程序员 | FPGA 工程师 + 上位机程序员 |
| 软件维护 | Linux 内核 + 驱动 + 设备树 + 应用层 | 零软件维护（纯硬件逻辑） |
| 启动时间 | Linux 启动 10-30 秒 | 上电即工作，微秒级 |
| 确定性延时 | 毫秒级（OS 调度抖动） | 微秒级（纯硬件，完全确定） |
芯片省一半，团队少一个人，代码零维护。 这不是理论推导，是实际量产项目的真实数据。
怎么做到的？答案就在一颗 UDP 桥接 IP 上。
核心武器：UDP 桥接 IP
整个方案的技术支点，是一颗以太网桥接 IP 核 （mstar_ethernet_bridge）。
它做的事情很简单，但很关键：
┌─────────────────────────────────────────────────────┐
│ FPGA 内部 │
│ │
│ ADC 采集 ──▶ DMA ──▶ DDR3 ──▶ ┌──────────────┐ │
│ │ UDP 桥接 IP │──────▶ 千兆网口
│ AXI Lite ◀──────────────────── │ (纯硬件逻辑) │ │
│ (寄存器配置) └──────────────┘ │
│ │
│ *** 没有 CPU *** 没有 Linux *** 没有协议栈软件 *** │
└─────────────────────────────────────────────────────┘这颗 IP 把完整的 UDP/IP 协议栈用纯 FPGA 硬件逻辑实现了。 FPGA 不需要任何 CPU 核，就能直接通过标准以太网与上位机通信。
上位机端就是一个普通的 UDP Socket 程序------收发数据、配置寄存器、控制采集------跟操作任何网络设备一样简单。
为什么省掉 ARM 核这么重要？
1. 成本：不只是芯片价格
用 SoC FPGA（如 Zynq、Cyclone V SoC），你付出的代价远不止芯片本身：
显性成本：
- SoC FPGA 芯片价格通常是纯 FPGA 的 3-5 倍
- 外围电路更复杂（DDR3 时序约束更严、电源域更多）
- 需要外挂 SPI Flash 存储 Linux 镜像
隐性成本（更致命）：
- ARM 端需要写 Linux 驱动、维护设备树、适配内核版本
- 一个 ARM/Linux 程序员的薪资 ≥ 一个 FPGA 工程师
- 产品生命周期内持续的软件维护成本（内核升级、安全补丁......）
2. 团队：ARM 程序员是项目延期的重灾区
很多应用系统的架构是这样的：
┌──────────┐ 网口 ┌─────────┐ AXI/中断 ┌─────────┐
│ 上位机 │ ◀────────▶ │ ARM │ ◀───────────▶ │ FPGA │
│ (C++/Qt) │ Socket通信 │ (Linux) │ 驱动+协议转换 │ (逻辑) │
└──────────┘ └─────────┘ └─────────┘中间的 ARM 程序员要干两件事：
- 向下：调试 ARM 与 FPGA 之间的通信（AXI 总线、中断、DMA、共享内存......）
- 向上：调试 ARM 与上位机之间的网口通信程序（Socket、协议解析、数据打包......）
一个人同时精通底层硬件接口和上层网络编程，本身就很勉强。实际上很多团队在 ARM 端配了 1 个以上的程序员 ------一个写驱动/底层通信，一个写应用/网络协议。即便如此，大多数项目的延期都卡在 ARM 端：
- AXI 时序调不通，FPGA 工程师和 ARM 程序员互相排查
- Socket 丢包/粘包，上位机程序员和 ARM 程序员来回扯皮
- Linux 内核升级，驱动要重写，整个链路重新验证
- 系统资源竞争（CPU/内存/中断），出问题定位极其困难
ARM 端成了整个系统的瓶颈------人最多、活最杂、延期最久。
而用纯 FPGA + UDP 桥接方案，架构变成：
┌──────────┐ 网口 ┌─────────────────────────┐
│ 上位机 │ ◀────────▶ │ FPGA │
│ (C++/Qt) │ UDP 直连 │ (纯硬件逻辑 + UDP IP) │
└──────────┘ └─────────────────────────┘没有 ARM，就没有 ARM 端的瓶颈。
| 对比项 | 上位机 + ARM + FPGA | 上位机 + FPGA（UDP 桥接） |
|---|---|---|
| 硬件端开发人员 | ARM 程序员 1-2 人 + FPGA 工程师 | FPGA 工程师 1 人 |
| 通信链路 | 上位机→ARM→FPGA，两段独立调试 | 上位机→FPGA，一段直连 |
| 联调复杂度 | AXI + Socket 两套协议同时调 | 只有 UDP 一套协议 |
| 延期高发区 | ARM 端（驱动/协议/资源竞争） | 不存在这个瓶颈 |
| 人员成本 | 多 1-2 个 ARM 程序员 | 省掉整个 ARM 软件团队 |
关键区别：
- FPGA 工程师一个人搞定硬件端全部工作，不需要 ARM 程序员介入
- 上位机端用任何语言都行（C++/Python/Qt/C#），门槛极低
- 接口协议就是 UDP 包的格式定义 + AXI Lite 寄存器映射，文档化程度高，不存在"联调黑箱"
3. 确定性：硬件逻辑 vs 操作系统调度
对于数据采集、工业控制、电机驱动这类场景，确定性延时比绝对带宽更重要：
| 指标 | SoC FPGA (ARM + Linux) | 纯 FPGA + UDP 桥接 |
|---|---|---|
| 控制回路延时 | 10μs - 1ms（含 OS 调度） | < 1μs（纯硬件逻辑） |
| 延时抖动 | ±100μs（不确定） | 0（完全确定） |
| 启动时间 | 10-30 秒（Linux Boot） | 上电即工作 |
| 看门狗恢复 | 需要重启 Linux | 硬件自动复位，微秒级恢复 |
Linux 不是实时操作系统。 哪怕打了 PREEMPT_RT 补丁，调度抖动仍然存在。对于需要微秒级确定性的应用，纯 FPGA 方案是唯一选择。
架构对比：什么时候该用什么
SoC FPGA (ARM + FPGA) 适合的场景
公平地说，SoC 方案并非没有用武之地。以下场景确实需要 ARM 核：
- 复杂协议栈：需要跑 TCP/IP 全栈、HTTP 服务器、MQTT 等高层协议
- 边缘计算：需要在设备端跑 AI 推理、图像预处理等计算密集型任务
- 文件系统：需要本地存储大量数据（SD 卡、eMMC）并管理文件
- 人机交互：需要跑 GUI（Linux framebuffer / X11）
- 遗留系统兼容：需要运行已有的 Linux 应用程序
纯 FPGA + 网口 适合的场景（比你想的多得多）
以下场景，ARM 核纯属多余：
- 数据采集：ADC → FPGA → DDR → 以太网 → 上位机（本文案例）
- 电机控制：编码器 → FPGA → 控制算法 → PWM 输出，上位机只做监控
- 逻辑转换/桥接：SPI ↔ 以太网、LVDS ↔ UDP 等协议转换
- 高速 IO 扩展：用以太网替代大量物理线缆，远端扩展 IO
- 触发/同步系统：多板卡微秒级同步，纯硬件逻辑保证确定性
- 波形发生器：DDR 存储波形数据 → DAC 输出，以太网配置参数
判断标准很简单：如果你的"CPU 端"只是在读写寄存器、收发数据、做简单控制------那它完全可以用 UDP 桥接 IP 替代。
UDP 桥接 IP 的功能特点与实际体验
笔者在实际项目中使用了以太网桥接 IP，下面介绍它的核心功能和实际使用感受。
详细介绍见：UDP 桥接 IP 介绍
IP 核心功能
| 功能 | 说明 |
|---|---|
| 内置数据校验 + 错误重传 | 硬件级数据校验和自动重传机制，确保 UDP 数据包不丢包------这是它区别于原生 UDP 的关键特性 |
| 多厂商 FPGA 支持 | 支持各公司 FPGA 芯片，特别是国产 FPGA（安路、紫光同创等），不绑定特定平台 |
| ARP / ICMP 协议 | 内置 ARP 协议和 ICMP 协议，支持 ping 命令，方便网络连通性诊断 |
| 千兆以太网 | 支持 RGMII 千兆 MAC + PHY，理论带宽 125 MB/s |
| 标准 AXI 接口 | 对外暴露 AXI Stream（数据流）+ AXI Lite（寄存器配置），与 FPGA 内部逻辑无缝对接 |
重点说一下"不丢包"这个特性。 标准 UDP 是不可靠协议，很多工程师不敢在关键场景用 UDP，就是怕丢包。这颗 IP 在硬件层实现了数据校验和错误重传，应用层完全不需要自己写确认/重传逻辑------用 UDP 的成本，拿到 TCP 的可靠性，而且是纯硬件实现，零 CPU 开销。
使用体验
1. 接口极其简洁
IP 核对外暴露的就是 AXI Stream + AXI Lite 接口：
verilog
// 上位机 → FPGA：配置寄存器
axi_lite_if u_axi_io (
.axi_awaddr(reg_addr),
.axi_wdata (reg_data),
.axi_araddr(reg_addr),
.axi_rdata (reg_rdata),
...
);
// FPGA → 上位机：数据上报
axi_stream_if u_tx (
.tx_tdata (payload),
.tx_tvalid(tx_valid),
.tx_tready(tx_ready),
...
);FPGA 工程师不需要理解 TCP/IP 协议细节，只需要关心"寄存器地址"和"数据流"。
2. 上位机开发零门槛------提供调试好的 DLL，无须从 Socket 开始编程
IP 供应商提供了经过充分调试的 MstarEthBridge.dll（Windows）/ .so（Linux），上位机程序员无须从 UDP Socket 开始编程，直接调用封装好的 C 接口函数即可。
主要接口函数一览：
| 函数 | 功能 | 典型用途 |
|---|---|---|
mstar_ethbridge_open() |
打开桥接服务，初始化网络连接 | 程序启动时调用一次 |
scan_device() |
广播扫描在线设备 | 发现设备、刷新设备列表 |
get_device() / get_device_ip() |
获取设备句柄 | 后续所有操作的入口 |
axilite_read() / axilite_write() |
控制总线读写 | 配置寄存器、读取状态 |
axilite_batch_rw() |
批量读写（单包多操作） | 高效配置多个寄存器 |
axifull_read() / axifull_write() |
高速总线读写 | 大块数据传输（采集数据、波形） |
i2c_read() / i2c_write() |
I2C 总线读写 | 操作外部、传感器、EEPROM 等 |
set_framlen() / set_framdelay() |
设置包长/包间隔 | 优化大数据传输性能 |
device_lock() |
锁定设备控制权 | 多主控端场景防冲突 |
mstar_ethbridge_close() |
关闭服务，释放资源 | 程序退出时调用 |
典型使用流程（C++）：
cpp
#include "MstarEthBridge.h"
// 1. 打开桥接服务
mstar_ethbridge_open(nullptr); // 广播发现设备
// 2. 获取设备句柄
MHANDLE dev = get_device(0); // 按索引获取
device_lock(dev); // 锁定控制权
// 3. 配置寄存器（控制总线）
uint8_t cfg[] = {0x01, 0x00, 0x00, 0x00};
axilite_write(dev, 0x1000, cfg, 4);
// 4. 读取采集数据（高速总线）
uint8_t buf[4096];
int len = axifull_read(dev, 0x00000000, buf, 4096);
// 5. 释放
axifull_write(dev, 0x00000000, buf, 4096); // 写回波形数据
device_handle_release(dev);
mstar_ethbridge_close();不需要写 Socket，不需要理解 UDP 协议细节，不需要处理字节序------调用 DLL 函数就像调用本地 API 一样简单。
3. 调试方便
所有通信都是标准 UDP 包，用 Wireshark 就能抓包分析。寄存器定义文档化后，FPGA 工程师和上位机工程师可以独立开发、独立调试，通过 UDP 包格式对接。
需要注意的地方
- IP 核为加密网表：无法查看内部实现，需要信任供应商
- 带宽上限：千兆以太网实际有效带宽约 100 MB/s，对于大多数采集场景已经足够
一个典型的纯 FPGA + 网口系统架构
以笔者的多通道数据采集项目为例，完整的系统架构如下：
┌─────────────────────────────────────────────────────────────┐
│ FPGA 端（纯硬件逻辑） │
│ │
│ ┌─────────┐ ┌──────────┐ ┌───────┐ ┌────────────┐ │
│ │ 8路 ADC │──▶│ 采集状态机 │──▶│ AXI │──▶│ DDR3 │ │
│ │ CM2268 │ │ (触发/预采)│ │ DMA │ │ 数据缓冲 │ │
│ └─────────┘ └──────────┘ └───────┘ └─────┬──────┘ │
│ │ │
│ ┌─────────┐ ┌──────────┐ ┌───────────────────▼─────┐ │
│ │ AXI │ │ UDP 桥接 │ │ UDP 桥接 IP │ │
│ │ Lite │◀──│ IP 核 │◀──│ mstar_ethernet_bridge │ │
│ │ 寄存器 │ │ │ │ (加密网表 IP) │ │
│ └─────────┘ └────┬─────┘ └─────────────────────────┘ │
│ │ │
└─────────────────────┼────────────────────────────────────────┘
│ 千兆以太网 (UDP)
▼
┌─────────────────────────────────────────────────────────────┐
│ 上位机 PC │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌───────────────┐ │
│ │ UDP Socket │──▶│ 数据解析/存储 │──▶│ Qt 波形显示 │ │
│ │ 通信线程 │ │ │ │ │ │
│ └──────────────┘ └──────────────┘ └───────────────┘ │
│ │
│ *** 标准 Socket API *** 无驱动 *** 无内核适配 *** │
└─────────────────────────────────────────────────────────────┘整个系统没有一行运行在 CPU 上的代码（FPGA 端）。 所有逻辑都是纯硬件实现，上电即工作，确定性延时，零维护。
开源参考设计
上述架构已在实际项目中验证，完整工程代码已开源，供参考：
| 项目 | 说明 | 仓库地址 |
|---|---|---|
| 设备端 FPGA 工程 | 安路 PH1 FPGA，含 ADC 驱动、DMA、UDP 桥接等全部 RTL 源码 | mstar-collect-fpga |
| 上位机软件 | Qt 跨平台桌面应用，波形显示、数据导出、设备管理 | mstar-oscilloscope |
说明：
- FPGA 工程中的
mstar_ethernet_bridge.ipr.v为 UDP 桥接 IP 供应商提供的加密 IP 网表，接口已完全开源 - 上位机软件使用标准 UDP Socket 通信，无任何私有协议或驱动依赖
- 两个仓库均可直接 clone、编译、运行，快速验证"纯 FPGA + 网口"架构
成本对比：算一笔详细的账
以一个年产 1000 台的设备为例：
方案 A：SoC FPGA (Zynq 7020)
| 成本项 | 单价 | 说明 |
|---|---|---|
| Zynq 7020 芯片 | ¥200 | 含 ARM Cortex-A9 双核 |
| DDR3 4GB | ¥80 | 需更严格的时序约束 |
| SPI Flash 32MB | ¥15 | 存储 Linux 镜像 |
| 电源管理 | ¥30 | 多电压域，设计复杂 |
| 硬件 BOM | ¥325 | |
| ARM 程序员 (1人) | ¥25万/年 | 写驱动、维护 Linux |
| Linux 软件维护 | 持续 | 内核升级、安全补丁 |
方案 B：纯 FPGA + UDP 桥接 IP
| 成本项 | 单价 | 说明 |
|---|---|---|
| 安路 PH1 FPGA | ¥45 | 纯 FPGA，无 ARM 核 |
| DDR3 4GB | ¥80 | 约束更宽松 |
| 无需 SPI Flash | ¥0 | 无 Linux 镜像 |
| 电源管理 | ¥15 | 单电压域，设计简化 |
| UDP 桥接 IP | 一次性授权 | IP 供应商提供 |
| 硬件 BOM | ¥140 | |
| 上位机程序员 | 已有 | 不增加额外人员 |
| 软件维护 | 零 | 纯硬件逻辑，无需维护 |
综合对比
| 指标 | 方案 A (SoC) | 方案 B (纯 FPGA + UDP) |
|---|---|---|
| 单台硬件成本 | ¥325 | ¥140 |
| 年省硬件成本 (1000台) | --- | ¥18.5 万 |
| 额外开发人员 | ARM 程序员 1 人 | 0 人 |
| 年省人力成本 | --- | ¥25 万 |
| 软件维护工作量 | 持续 | 零 |
| 年综合节省 | --- | ¥43.5 万+ |
这还没算 SoC 方案中 Linux 适配、驱动调试、系统裁剪所消耗的时间成本。
常见疑问解答
Q1：不用 ARM，FPGA 怎么处理复杂逻辑？
FPGA 本身就是为复杂逻辑而生的。状态机、流水线、并行处理------这些是 FPGA 的强项。你不需要一个 CPU 来"管理"FPGA，FPGA 自己就能管理自己。
需要"配置"的部分（如采样率、触发阈值），通过 AXI Lite 寄存器暴露给上位机，上位机用 UDP 包写入即可。
Q2：UDP 不可靠，丢包怎么办？
这颗 IP 的 UDP 桥接模块内置了数据校验和错误重传机制，在硬件层保证了 UDP 数据包不丢包。应用层完全不需要自己写确认/重传逻辑------用 UDP 的成本，拿到 TCP 的可靠性，而且是纯硬件实现，零 CPU 开销。
Q3：这颗 IP 支持哪些 FPGA 平台？
支持各公司的 FPGA 芯片，特别是国产 FPGA（安路、紫光同创等），不绑定特定平台。具体型号和授权方式，建议直接联系 IP 供应商确认。
Q4：这个方案能替代 SoC FPGA 吗？
不是替代，是互补。 如果你的应用确实需要跑 Linux、跑 AI 推理、跑复杂协议栈，SoC FPGA 是正确的选择。
但如果你的"CPU 端"只是在读写寄存器、收发数据、做简单控制------那 CPU 核就是多余的。用一颗 UDP 桥接 IP，让纯 FPGA 直接对接以太网，省成本、省人力、省维护。
总结
| 维度 | 传统 SoC FPGA 方案 | 纯 FPGA + UDP 桥接方案 |
|---|---|---|
| 芯片成本 | 高（含 ARM 核） | 低（纯 FPGA） |
| 开发团队 | FPGA + ARM 程序员 | FPGA + 上位机程序员 |
| 软件维护 | Linux 驱动/内核持续维护 | 零维护 |
| 启动速度 | 10-30 秒 | 上电即工作 |
| 确定性延时 | 毫秒级（OS 抖动） | 微秒级（纯硬件） |
| 适用场景 | 复杂计算/协议/边缘 AI | 数据采集/控制/桥接 |
核心观点： 很多工程师习惯了"遇到问题就加个 ARM 核"的思路。但当你了解了 UDP 桥接 IP 之后，你会发现------好多场景，一颗纯 FPGA + 一根网线，就够了。
省掉的不仅是一颗 ARM 核的成本，更是一个 ARM 程序员的人力成本、Linux 软件栈的维护成本、以及系统启动的等待时间。
如果你的应用不需要 Linux，为什么要为 Linux 买单？
本文基于实际量产项目经验撰写。文中提到的 UDP 桥接 IP 已在安路 PH1 系列 FPGA 上验证通过。