AI编码智能体在Chiplet RTL调试中遇阻，三项工具改进将修复时间缩短至21分钟

我让一个AI编程agent去修复Caliptra（CHIPS Alliance推出的一款大型开源系统级芯片，它是一个硬件信任根：一个带有自家RISC-V处理器和固件的安全模块）内部RISC-V（一种开放指令集架构，许多开源处理器核心都实现了它）处理器中的一个bug。它通常在五分钟内就能找到出问题的RTL（寄存器传输级：描述芯片硬件逻辑的代码，通常用Verilog或SystemVerilog编写。仿真器负责运行它，综合工具则把它转成门级电路）代码行。但证明修复有效却花了长得多的时间，因为agent首先得让这个bug在仿真中显现出来。在十多次试验中，大部分时间都耗在两个硬件特有的问题上：解释失败原因的內部信号除非仿真时记录了它们，否则根本看不到；而仿真运行时间又足够长，agent只能靠猜来判断它们何时结束。第三个问题是构建过程依赖于agent的shell不会保留的设置，这虽然不是硬件特有的，但在RTL项目中很常见。借助针对这三个问题的工具，同一个agent从开始到验证修复的平均时间从56分钟降到了21分钟。

编程agent主要是为软件工作打造的。它们的工作循环假设：测试几秒内就能跑完，失败时会打印出有用的信息，命令可以廉价地反复重跑。硬件设计把这三条全打破了。芯片用RTL（寄存器传输级：描述芯片硬件逻辑的代码，通常用Verilog或SystemVerilog编写。仿真器负责运行它，综合工具则把它转成门级电路）代码描述，并在仿真器中测试。大型设计的仿真编译和运行都要花好几分钟，所以每次重跑都很昂贵，而解释失败原因的状态又藏在没人打印出来的内部信号里。

当前的模型对RTL的推理能力不错。本文关注的是，当这种推理遇上真实的硬件调试循环时会发生什么。它追问agent的时间都花在了哪里，其中哪些时间来自硬件工作而非agent配置本身的一般性问题，以及agent的harness（围绕AI agent的环境：它能调用哪些工具、它的命令如何运行、它收到哪些指令）能对此做些什么。

范围限定在调试：找到bug、复现它、证明修复有效。其他RTL任务，比如编写新设计代码或搭建验证环境，会遇到不同的问题。后续文章会讨论这些。

为了回答这个问题，我让同一个agent在两种环境下处理同一个bug：一个是普通shell，另一个是Booley——一个面向FPGA和ASIC工作的开源agent harness。Booley是我自己构建的，这个实验也是我本人跑的，所以看待这个对比时请把这一点考虑进去。不过，下面描述的问题都来自普通shell的运行，适用于任何面向RTL的agent环境。

我想要一个这样的bug：限制agent的是环境，而不是模型的推理能力。我从CVDP（NVIDIA的硬件设计与验证问题基准）的一个子集里的bug修复任务开始。那些任务对这个问题来说太小了：agent用任何工具都能很快解决，环境根本没机会发挥作用。我需要一个复现bug需要真正仿真工作的设计。

于是我去找我能找到的最大的高质量开源RTL代码库。我选了Caliptra，一个硬件信任根：一个带有自家处理器和固件的安全子系统。

我最终选定VeeR EL2（Caliptra内部的RISC-V处理器）中的一个历史bug，并通过回退VeeR EL2 1.4版本中的一个上游修复来重新引入它。

在bug报告描述的场景中，固件在启动期间检查处理器ROM（只读存储器，这里存放处理器的启动程序）的内容。在某组特定的读写序列下，即使存储的程序是正确的，这个检查也会失败：ROM地址0处的字读回来是零。

agent的任务是找到并修复RTL中的原因，然后添加一个在修复前失败、修复后通过的测试。

agent收到了一份issue风格的报告，描述了这个行为：

启动早期，固件会对自己ROM镜像重新计算摘要，并与构建时固定的常量比较。正常情况下检查能通过。但在一种情况下，摘要算出来是错的，尽管ROM没变、常量也正确。没有故障、没有异常、没有ECC事件，完全确定性地复现。触发条件是一种编码模式：出错的例程逐字读取ROM，并在同一个紧凑循环中把部分结果写入DCCM（数据紧耦合内存：处理器快速的片上数据内存，不经过系统总线访问）中的暂存缓冲区。把累加器放在寄存器里，或者把缓冲区移出DCCM，摘要就正确了。只有ROM输入的第一个字看起来被损坏了。

找到并修复RTL根本原因。添加一个能复现问题、并在修复后通过的测试。

上游发布说明把这个修复描述为“当地址为0x0时，存储数据与DCCM DMA错误发生冲突”。

该处理器使用存储到加载转发：读操作可以直接从最近对同一地址的写操作取值，而不必等待内存。为了省电，它还会把发往片上数据内存（DCCM）的写操作的地址和数据都置零。转发检查漏掉了“这个写操作是要发到总线上的”这一条件，于是它把每次读操作都与那个置零的地址0比较。一次紧接在片上写之后发出的、来自ROM地址0的读操作“匹配”上了，跳过了真正的ROM读取，拿到了置零的值：零。

在两种环境中，agent通常都能在五分钟内识别出出问题的代码行。然后它必须写一个在原始设计上失败、修复后通过的测试。这能证明故障存在，并有助于在故障日后回归时抓住它。

有两个细节让这个测试很难写：

大部分工作都花在构建测试、仿真它、检查发生了什么，并调整它直到它以正确的原因失败上。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）