芯片 Agent 非得从 RTL 写起吗？

芯片设计 Agent 该从哪一层开始动手？如果入口固定在 RTL，模型就要同时处理算法、并行架构、周期行为和接口细节。设计自由度很大，犯错和错过优化的机会也多。

9 月 17 日提交 arXiv 的 AHRR 论文，给出了一条值得测试的路径：先让 Agent 写 HLS C++，由高层次综合工具生成 RTL，再让 Agent 优化生成结果。作者在 FPGA 评测中报告，相对直接 RTL 设计，组合流程取得约 2.6× 几何平均加速。

先别把加速倍数换算成研发工时。这里测的是生成硬件的执行时间。论文更有启发的地方在于，把成熟编译工具已有的设计知识交给 Agent 使用，可以先缩小架构探索范围，再把低层优化机会留给 RTL 阶段。

先把 2.6× 的账算明白

AHRR 的全称是 Agent-based HLS with RTL Refinement，即 Agent 驱动 HLS 设计并继续精修 RTL。论文比较四条路径：直接写 RTL；Agent 写 HLS；优化 HLS 生成的 RTL；从领域编译器生成的 HLS 代码继续优化。AHRR 特指第二条接第三条，领域编译器路径另行评测。

任务套件包含 11 项，覆盖 LLM 推理、检索与缓存、机器人计算和矩阵乘法。实验使用 AMD Alveo U55C、Vitis 2025.2，以及两个模型，在相同 Agent 框架下运行。每项实验只跑一次。部分工作负载缩小规模，部分采用定点算术，结果不能代表所有真实应用。

硬件执行时间由仿真周期数乘以时钟周期计算；时钟周期取布局布线结果与目标周期的较大值。设计还必须通过隐藏 testbench、完成布线，并满足资源上限。评测采用不含 shell 的模块级实现，因而也没有给出完整板卡应用的端到端运行成绩。

表 3 中，AHRR 的几何平均加速为 2.62×，纳入 13 个具有有效直接 RTL 基线的任务—模型配对；不能理解成 11 项任务全部成功、全部提速。仅 HLS 的 2.31× 则纳入 15 个配对，样本集合不同，不能直接相除当作 RTL 精修的独立贡献。

这组比较回答的是：在作者规定的任务、模型和预算下，哪条路径更容易得到执行更快的有效硬件。它没有回答 Agent 是否超过资深工程师，也没有证明 ASIC PPA、工业 sign-off 或生产部署。

HLS 给 Agent 的，是可调用的设计知识

HLS 用 C/C++ 表达计算，再把调度、流水和资源绑定等工作交给工具。Agent 仍要选择循环结构、并行度、存储组织和优化指令，工具负责把这些意图落实为硬件。

直接写 RTL 时，同样的并行意图必须变成明确的数据通路、控制逻辑和寄存器关系。模型即使写出功能正确的代码，也可能保守地选择较窄的数据通路，留下性能差距。

论文中的非极大值抑制任务提供了具体例子。它需要反复选出最高分候选框，再过滤重叠框。每周期能处理多少候选框，影响总周期数。作者展示的 HLS 设计通过数组分区和流水指令表达 256 路并行；直接 RTL 设计则分别采用 32 路选择和 8 路过滤。

工具替 Agent 生成了比较树与流水寄存器，但并行度也有价格：该案例中 HLS 生成结果用了约 11.8 万 LUT，直接 RTL 版本约 5454 个。执行更快与资源更少在这里分开了。评估路径时，只盯加速倍数会漏掉关键成本。

从工程机制看，HLS 把一部分结构设计知识封装进了编译过程。Agent 可以用较短的高层表达调用它，却仍需靠综合和实现报告判断资源、访存与时序是否承受得住。写下流水指令，也不等于目标启动间隔一定能实现。

RTL 精修怎样接手

HLS 建好起点后，生成 RTL 仍可能暴露冗余运算和关键路径问题。Agent 在这一层工作，可以对具体结构动刀。

论文的 MEM3 案例计算两个乘积，再选择较大者。Agent 根据乘数符号，先选择另一个操作数，再做一次乘法。作者报告 DSP 从 64 个降到 32 个，LUT 从 4868 个降到 2228 个，周期数基本不变。

这次修改先省下了一半乘法资源。有限位宽硬件还要检查符号扩展、截断和溢出，数学表达式上的等价不能自动代替 RTL 行为验证。还要留意指标公式：该案例时钟周期从 3.14 ns 改善到 2.83 ns，但评测目标为 3.33 ns，指标公式不会把低于目标周期的全部改善记作执行时间收益。

RTL 阶段也不总是“改几行”。论文指出，大幅降低延迟的成功尝试来自完整重写；多数局部编辑带来的周期数改善较小。团队应区分保留接口和调度结构的精修，与推倒实现后的重新验证，二者的维护成本差别很大。

架构问题留在高层，路径问题下沉到 RTL

另一个卷积案例把两层分工串了起来，但它走的是领域编译器起步的扩展路径，应与 AHRR 主比较分开看。

StreamHLS 生成的初始设计保存四个本地数组，还额外填充一个带边界的数据副本。Agent 在 HLS 层改用两行缓冲和一个 3×3 窗口，删除填充阶段。作者报告周期数从 539726 降到 209297，BRAM 从 224 个降到 2 个。

随后，Agent 在 RTL 中识别常量操作数乘法，把相关模块替换为查找表。周期数不变，时钟周期从 4.20 ns 降到 3.82 ns。前一步改变数据保存和复用方式，后一步改善具体实现路径。

顺着这个案例看，团队可以按瓶颈选择修改层级。整块数组是否需要存在、循环怎样组织，适合在高层表达；冗余运算、生成模块和组合路径，则可以结合 RTL 与实现报告处理。工具反馈告诉 Agent 瓶颈在哪里，再决定回哪一层修改。

验证预算决定能走多远

作者给每个 Agent 轮次最多一小时，最多五轮；RTL 仿真与综合布局布线也设有超时。部分较大设计的仿真时间接近上限，留给优化的反馈机会很少。

同样五轮，快速返回报告的任务与接近超时的任务，实际探索空间并不相同。模型提出更多候选，如果工具来不及评价，搜索就停在提交队列里。工具时间、有效反馈次数和失败原因，应该一起进入 Agent 评估。

隐藏 testbench 比单个公开测试激励更有约束力。论文还将 C++ 参考实现的分支覆盖率加强到 100%，并测量参考 RTL 的覆盖率。但参考程序分支全部走到，仍无法证明所有时序行为、协议组合和异常输入都正确。

作者仓库公开了任务、评测记录和复现入口，便于外部检查。 可复现材料与独立复现结果是两个状态；本次未运行完整 FPGA 工具链。后续真正有分量的证据，是其他团队在自己的任务和预算下跑出怎样的成功率与结果分布。

企业试点，先选瓶颈再选入口

判断类似流程，可以问三件事：瓶颈位于哪一层，结果如何验收，收益付出什么代价。

若任务主要是规则计算、循环并行与数据复用，HLS 起步值得对照测试。若核心需求是精确周期控制、特殊协议或既有 RTL 集成，直接 RTL 应保留为候选。论文中直接 RTL 在部分小任务上胜出，足以提醒团队避免把组合路径定成唯一入口。

验收则需要稳定接口、独立参考、错误定位和修改后的回归。手工优化生成 RTL 后，还要解决再生成会覆盖修改的问题：保留可追踪补丁，还是把优化回写到高层源代码，需要在流程中明确。这类 AI+EDA 落地，需要把专业模型、企业知识和流程编排接到人工 review 节点上，让候选设计、工具报告与验收记录留在同一研发流程里。

成本应分开记录硬件资源、执行时间、EDA 工具时间、模型调用与人工接管。算法工程师关注数值和数据复用；RTL 工程师关注接口、周期与修改范围；CAD 和验证负责人关注回归、工具版本与可追踪记录。研发负责人最终要看总成本和交付质量。

AHRR 提供了一个有实验支撑的流程选择：Agent 先借 HLS 建立架构，再到 RTL 处理剩余优化机会。它值得被放进企业试点的对照组。

决定采用哪条路径时，应让瓶颈定位、独立验证和成本记录共同作答。若一次高层修改能消除大块无效存储，就回到高层；若问题藏在具体运算结构和关键路径，就检查 RTL。每次跨层修改都留下可复核证据，这套分工才有机会从论文走进工程。

作者：麒芯

声明：本文依据公开资料分析，实验数据为论文作者 FPGA benchmark，未由本任务独立复现，不代表 ASIC PPA、工业 sign-off 或生产部署。

参考资料

1. arXiv：Can Agents Design Better Chips with a Higher Level Abstraction?

2. ZijD/AHRR：作者代码、任务与评测材料

3. AMD：Vitis High-Level Synthesis User Guide（UG1399）