一人用AI搭建开源AI加速器，已经在FPGA上运行

现在编写寄存器传输级（RTL）代码已经变得越来越容易，但难点在于从RTL设计得到真正可用的硬件芯片。

开发者kevingubbi研究了@BonettoSens开发的openTPU项目，这是一个由AI智能体构建的开源AI加速器，可以在Kintex-7现场可编程门阵列（FPGA）上运行大约10个当前主流大语言模型（LLM）。

项目包含Python模拟器、指令集架构（ISA）/编译器、RTL设计、FPGA实现，并且可以实际输出 tokens。作为一个基本上由单人完成的项目，成果相当令人印象深刻。

如果要进一步推进这个项目，kevingubbi提出了四点发展方向。

第一，从FPGA原型到专用集成电路（ASIC）/片上系统（SoC）实现，这是一个相当大的工程步骤。

目前这个项目的实现围绕Kintex-7 FPGA、数字信号处理器（DSP）/块随机存取存储器（BRAM）、DDR3 + LiteDRAM等组件完成，当前时序收敛后可以运行在133MHz，最坏负偏差（WNS）为+0.032纳秒。

现有的ISA和编译器设计思路可以沿用，但具体实现需要大量重新设计，包括SRAM宏单元、存储层次结构、时钟/复位、可测试性设计（DFT）/内建自测试（MBIST）、功耗、布局规划、时序、IR压降/电迁移、物理签核等环节。

去掉FPGA的约束后，会有更多参数可供调整，比如不同的计算架构、缓存方案、存储层次，以及量化数据通路、计算存储配比是否需要调整。这本质上是设计空间搜索问题，设计自由度提升后，可能的实现方案数量会快速增长，因此在进入实现阶段前，需要先完成大量架构和设计空间探索工作。

第二，验证与覆盖收敛。

当前的验证框架已经具备实用价值，通过随机和模型级工作负载，将RTL设计和Python模拟器做对比，可执行参考模型是很好的基础。但如果要推向ASIC/SoC，需要增加更深层的验证层。

和模拟器匹配只能说明已经运行的执行过程是正确的，但仍需要知道哪些场景还没有覆盖到，比如反压、仲裁、复位序列、特殊指令组合、低使用率模式、边界条件等。

当前仓库中没有系统化的断言/形式化验证/覆盖收敛流程，因此很难判断状态空间中哪些部分已经被验证过。此外还有X态问题：当前流程大多依赖Verilator，基本是二态仿真。对于ASIC/SoC流程，还需要增加对X敏感的四态仿真流程，再补充断言、覆盖、形式化验证、时钟域交叉/复位域交叉（CDC/RDC）验证。

第三，工程化与工作流扩展。

当前项目明显是为单人快速开发优化的，这也让项目能达到现在的完成度更显出色。但如果项目后续发展到有5到10名工程师同时修改RTL/编译器/微架构，配套工程基础设施也需要同步扩展，包括更快的预提交测试、更深度的回归测试、可复现环境、持续集成（CI）、覆盖跟踪等。这不是对当前架构的批评，只是项目从单人快速开发转向多人团队协作后必然会遇到的新问题。

第四，AI智能体与硬件闭环。

这是这个项目带给kevingubbi最主要的启发：有意思的点不是AI智能体会写RTL，因为Claude、Codex等代码智能体已经具备这个能力，而且还会不断进步。真正重要的是围绕AI智能体形成的闭环。

智能体修改硬件设计，模拟器给出参考，RTL通过校验，综合/性能功耗面积（PPA）给出信号，实现阶段再给出更多反馈，智能体根据这些反馈回去再次修改设计，专用硬件工具就是在这个环节发挥作用的。

不一定需要为硬件设计完全不同的模型，但智能体需要获取硬件相关的反馈，比如功能是否保留、覆盖度是否提升、时序是否优化、面积是否缩小、功耗是否恶化、修改后的设计是否能通过综合和物理实现。如果只反馈“修改是否匹配模拟器测试结果”，那智能体就只能学会解决这个问题；如果给智能体提供断言、覆盖、形式化验证、X敏感仿真、时序/PPA和物理实现的多维度反馈，就能让它更清楚地知道什么是好的硬件设计。

总体来看，这是一个非常出色的概念验证项目，尤其是作为单人项目成果突出。上述提到的很多问题，本身就是从可用的FPGA原型转向大规模ASIC/SoC开发过程中必然会遇到的问题。如果你想了解AI加速器如何从Python/软件一路实现到RTL和可用的FPGA硬件，可以去完整浏览这个项目仓库。