观点 · 我们的使命

我们为什么把从算法到芯片这条路自动化

高性能的射频和 FPGA 硬件,大多数时间都在闲置。要做的事并不少,缺的是一条可信的路径, 把一个算法跨越到这些硬件上能跑的系统。把这条跨越搭起来,就是我们做的事。

AlgoSilicon 工程团队 · 2026

一个研究组或产品团队,买了一台和一辆车差不多贵的 SDR 或 FPGA 板卡。跑几次 数据采集,板卡就上了架。这些硬件本可以做得多得多,远不止简单的收发。它之所以闲置,是 因为在上面做真正的定制开发,确实很难。

算力买得起,却用不起来

门槛分两段,一个项目两段都得迈过去。

第一段,是把软件算法变成高效的硬件。CPU 一条接一条地执行指令;FPGA 在同一个时钟节拍 里跑成百上千个运算。同一个算法,写成能跑,和写成又快又省,是两个不同的设计,两者之间的 距离是一门专门的手艺。

第二段,是让这套硬件真正在板子上跑起来:接口、数据搬运、驱动,以及外面那层应用。这 需要一个既懂底层逻辑、又懂上层软件的人,而且一旦出问题,很难判断是哪一层坏了。

这两段门槛叠在一起,让昂贵的硬件用不充分,也让愿意学这门手艺的人越来越少。

昂贵的硬件被两段门槛挡住而闲置:把软件算法变成高效逻辑,以及把逻辑集成到板上跑起来
一个算法和板上能跑的系统之间,隔着两段门槛:写出高效的硬件,再把它集成到 真正能跑。

现有工具为什么还差一口气

厂商做了不少工具来降低门槛。USRP 有 RFNoC。AMD 和 Xilinx 有 PYNQ 配合高层次综合。 MathWorks 有 Simulink 配合 HDL Coder。它们有帮助,可共同的体验还是一样:Demo 能跑,一旦 换成你自己的设计,问题就冒出来。整个流程要大量手动改文件、改参数,工具版本还更新得快。

把抽象层抬高,本身并不能填平这道沟。高层次综合被反复记录有一道生产率与性能之间的取舍: 选对那些优化指令、把代码重构得对硬件友好,仍然需要很深的硬件经验,而且和手写 RTL 之间还有 一道实打实的频率差距。

更新的一条路,是直接让大语言模型写 Verilog,它有个绕不过去的问题:模型生成的硬件看着 合理,功能却是错的。在标准的 Verilog 评测上,功能正确率从大约六成,升到了最好方法的九成 左右,剩下的那部分仍然是错的,没有一种方法能把它彻底消除。缺的那块,是可信。

现有工具(RFNoC、PYNQ 配高层次综合、Simulink 配 HDL Coder)留下一道沟:Demo 能跑但换成自己的设计就崩,流程靠手动,模型直接写还会幻觉
现有工具留下同一道沟:Demo 能跑,换成自己的设计就崩,流程仍要手动,让模型 直接写 RTL 又会生成错的硬件。

我们在做的事

我们在做一套 AI 驱动的自动化工具,把一个 Python 算法,经过优化、可验证的 RTL IP,做成 在真实硬件上整系统集成、能运行的产品。目标不只是 FPGA。同一套流程也面向主机 CPU、嵌入式 ARM,以及新兴的 GPU 与 NPU 加速器,让它们协同工作。

几段都已经走通。流程能从 Python 算法生成优化过的 RTL IP,我们也从 MATLAB 经高层次综合 C 做过同样的事。它自动完成时序收敛、把资源用到最省,这些都是 FPGA 工作里没人爱做的部分。 它还把设计搬上板:自动化的系统集成、前仿后仿,以及板上测试。

串起来,就是一条从 Python 算法到板上能跑产品的流水线。算法在最前面,能跑的系统在最后 面,中间又难又琐碎的部分,交给框架和 AI。

一条流水线:Python 算法到优化的 RTL IP,到系统集成,到板上产品,落在 FPGA、ARM、CPU、GPU、NPU 上
一条流水线,从 Python 算法到板上能跑的产品,落在部署所需要的处理器上。

怎么让 AI 造的硬件可信

这是整件事的核心。让 AI 写硬件不难,难的是让它写出你能信得过的硬件。我们的做法,是一条 三层链子,每一层都是下一层的基准,外加一圈护栏。

三层是数学、周期、电路。一个对照权威标准校验过的数学模型,是对错的裁判。一个逐拍对齐 硬件的周期精确 Python 模型,跟着硬件一个时钟一个时钟地走。Verilog RTL 从这个模型翻译出来, 再对它核对。做核对用的向量,由数学层生成,从不手写。三层逐字节一致,否则不放行。

这正是它和高层次综合的区别:后者是个黑盒,不保证逐比特一致;也是它和裸用大模型的区别: 模型那些看着合理实则出错的输出,过不了逐字节这道闸门,根本到不了下一层。链子之外是一圈 护栏,每一条都有自动检查把守:任何数字都要能追到当次的工具报告,先量后改,带反馈的通路 上板前要在综合后网表上重新核对,连续工作的设计要背靠背、中间不复位地验证。

可信的 AI 硬件,来自每一步都对一个独立基准核对到比特,与模型是否聪明无关。

一条三层链子(数学、周期、电路)每一步逐字节核对,外加一圈护栏,并与作为黑盒的 HLS、会幻觉的裸大模型对照
三层逐字节核对,外加一圈自动护栏。错的硬件过不了通往下一层的闸门。

在一个 Wi-Fi 接收机上验证

这套方法在一个真实系统上得到了验证。我们生成了一个完整的 802.11a Wi-Fi 接收机,把它在 ADALM-Pluto 上跑了起来,板上是一颗入门级的 Zynq-7010。这个接收机太大,没法和射频自己的接口 逻辑一起塞进这颗小芯片,于是它拆成三层来跑:对速率敏感的前端在 FPGA 逻辑里,数据搬运在 嵌入式 ARM 上,译码后端在主机上。每一层都对同一个基准逐比特核对。

在空口上跑,这个接收机把全部八种 802.11a 数据速率,从 BPSK 到 64-QAM,一比特不差地收了 回来。

八种模式全过,空口实测
每一种 802.11a 数据速率都在 ADALM-Pluto 上逐比特恢复,前端在 FPGA、译码在主机

完整的讲解,包括接收机信号链、实测的时钟与资源数字,以及空口结果,都在这篇技术案例里: 一台 AI 自动生成的 Wi-Fi 接收机,逐比特验证

接下来

两个方向。一个是平台:从 ADALM-Pluto 推到更大的 USRP 和 RFSoC。另一个是处理器:从 FPGA 延伸到 CPU、ARM、GPU、NPU 协同。目标自始至终是一个:把从算法到芯片这条路,变成一条你能 信得过的自动化流水线,让人们已经买下的算力被真正用起来,而不是闲置吃灰。

接下来两个方向:平台从 Pluto 到 USRP 到 RFSoC,处理器从 FPGA 到 ARM、CPU、GPU、NPU 协同
接下来两个方向:更多平台,更多处理器协同。
在一个真实接收机上看这套方法

Wi-Fi 技术案例把同一套流程端到端走了一遍,每一个时钟和资源数字都是实测的。或者, 和我们聊聊你的算法。

阅读技术案例