 AI-ENABLED DESIGN VERIFICATION给 AI 一双「看波形的眼睛」基于 MCP 的 FSDB AI Debug 实践 在 AI-Enabled 芯片工程时代，AI 不应该只帮助工程师写代码、读文档和分析 Log，它还应该能够进入设计验证最核心的工作现场，直接查看波形、检查信号，并完成初步的 Debug 分析。 对于芯片设计验证工程师来说，波形分析几乎是无法绕开的工作环节。当 Testcase Fail、Assertion 触发、Scoreboard 报错，或者 DUT 行为与预期不一致时，工程师通常会打开 Verdi，加载 FSDB 波形，然后沿着时间、层级和数据路径逐层追踪。 Reset 是否在正确时间释放？ Clock 是否正常启动并持续翻转？ 总线握手为什么没有完成？ Interrupt 在什么条件下被拉高？ FSM 卡在了哪个状态？ Request 已经发出，为什么 Response 没有返回？ 某个信号为什么一直保持常量？ 这个信号是否被 Testbench 强制 Force？ 数据在时钟边沿前后是否稳定？ 这些问题看起来各不相同，但本质上都依赖同一类能力：在正确的时间窗口内，找到正确的信号，并理解这些信号之间的时序关系。 过去，这项工作高度依赖工程师手工操作波形工具。现在，我们可以通过 MCP 给 AI Agent 提供直接查询 FSDB 波形的能力，让 Agent 真正参与到芯片 Debug 的核心流程中。 第一部分：AI 如何进入波形 Debug 核心环节1. 从 AI-Assisted 走向 AI-Enabled过去两年，AI 在芯片设计验证领域的应用越来越广泛。工程师已经开始使用 AI 完成 RTL 和 UVM Code Review、Testplan 与 Assertion 生成、Regression Log 分析、Failure Cluster 分类、Coverage Hole 分析、Specification 问答、Debug Report 生成，以及 Python、TCL 和 Shell 脚本编写。但在许多实际工作流中，AI 仍然停留在外围。一个 Testcase Fail 之后，Agent 可以读取仿真 Log，并根据错误文本推测 Read Response 没有返回、Register Model 没有同步、Reset 没有释放、Bus Transaction 超时，或者 DUT 内部状态机卡住。问题在于，这些通常只是推测。 UVM_ERROR: Read data mismatch Expected: 0x12345678 Actual: 0x00000000 Time: 152340ns 如果 AI 无法访问波形，它就无法确认在 152340ns 之前 Request 是否真正发出，Valid 和 Ready 是否完成握手，Response Channel 是否返回有效数据，目标寄存器是否真的被写入，以及相关信号是否被 Testbench Force。 AI-Assisted Debug：AI 根据人类提供的 Log、截图和文字描述进行推理。 AI-Enabled Debug：AI 可以主动调用工程工具，获取证据，验证假设并继续调查。 真正的 AI-Enabled 并不是让 AI 给出更多猜测，而是让它能够主动执行验证动作。 2. 波形是芯片 Debug 中最重要的事实来源之一在验证环境中，不同数据源承担着不同角色：Specification 描述设计应该如何工作，RTL 描述设计逻辑如何实现，Testbench 描述测试如何激励和检查设计，Simulation Log 描述仿真过程中记录了什么，Coverage 描述哪些功能或代码已经被触达，而 Waveform 描述设计在每一个时间点实际上发生了什么。 波形提供了带时间维度的设计状态。对于一个协议事务，Log 可能只告诉我们最终超时，但波形可以展示 Request 生成、Address 接受、Data 传输、Target Busy、Response 缺失和 Timeout 触发的完整过程。
工程师可以根据波形，将一个模糊的"测试失败"逐步缩小到激励没有生成、信号没有到达 DUT、Interconnect 没有路由、Slave 没有响应、Clock 或 Reset 状态异常、CDC 路径出现问题，或者 Testbench Force 覆盖了设计行为。因此，如果希望 AI Agent 真正参与 Debug，就必须给它访问波形的能力。
|
| MCP Tool | 主要能力 | 典型用途 |
| fsdb_get_signals_at_hierarchy | 发现指定 Hierarchy 下的信号 | 进入陌生模块、定位 Clock/Reset/Interface/FSM |
| fsdb_get_signals_values | 查询 Value Change，或按条件、电平、周期采样 | 常规波形分析、握手定位、事件搜索 |
| fsdb_find_forces | 查询 Force/Release/Deposit | 排查 Testbench Override 和异常常量 |
| fsdb_get_signals_values_at_strobe | 在指定 Strobe Edge 上采样 | 同步逻辑、协议与 FSM 周期分析 |
| fsdb_get_signals_values_before_clk | 在边沿前偏移采样 | Setup Side 波形观察 |
| fsdb_get_signals_values_after_clk | 在边沿后偏移采样 | Hold Side 或边沿后状态观察 |
2.1 查询某个层级下的信号
fsdb_get_signals_at_hierarchy 用于发现指定 Hierarchy 下有哪些信号。Agent 可以先查询 /tb/dut/dut/*，再定位 Clock、Reset、Request、Acknowledge、Address、Data、FSM State、Interrupt 和 Error Status。这相当于工程师在 Verdi 中展开 Design Hierarchy 并查看某个 Instance 下的 Signals。
| 发现 Hierarchy | 列出信号 | 筛选关键信号 | 查询信号值 | 分析时序关系 |
FSDB 中的层级分隔符可能使用 "/" 或 "."。查询 Scope 时通常还需要带通配符，因此推荐 Agent 先从顶层或较短路径开始探索，再逐步进入目标模块。
2.2 查询信号的 Value Change
fsdb_get_signals_values 是最常用的工具。它可以查询一个或多个信号在指定时间窗口内的变化，例如检查 req、ack 和 state 在 100us 到 120us 之间的行为。若不指定特殊采样模式，工具返回信号发生变化的时间点和值，适合分析 Request 何时拉高、Acknowledge 是否返回、FSM 如何变化，以及 Error 是否在某个事件后出现。
2.3 根据条件表达式查询
condition_expression 对应 Fsdbreport -exp。例如 valid==1 && ready==1 可以只查看真正发生握手的时间点，reset_n!=0 可以帮助查找 Reset 离开初始值的时刻。典型用途包括第一次总线握手、Error Flag 首次出现、Interrupt 拉高、FSM 进入目标状态，以及 FIFO Full 或 Empty 条件发生。
2.4 按固定周期或电平条件采样
periodic_sampling_interval 对应 -period，例如每隔 100ns 采样一次目标信号，适合周期性状态检查、性能计数器、Heartbeat、FSM 和 Queue Depth 的趋势观察。levelstrobe 对应 -levelstrobe，适合 Enable、Chip Select、Power Domain On 或 Transaction Active 条件成立期间的采样。条件表达式、Level Strobe 和周期采样属于互斥模式，一次查询选择其中一种。
2.5 在 Clock 或 Strobe Edge 上采样
fsdb_get_signals_values_at_strobe 可以在 posedge clk 等指定边沿上采样 Data、Valid、Ready、FSM State、Counter 和 FIFO Pointer。它比普通 Value Change 更适合同步数字逻辑，因为 RTL 状态更新通常与时钟边沿相关。
2.6 检查时钟边沿前后的信号
fsdb_get_signals_values_before_clk 和 fsdb_get_signals_values_after_clk 分别用于 Strobe Edge 前后偏移一定时间进行采样，可辅助观察边沿前的数据稳定性，以及边沿后的状态与输出。需要注意，这类查询不是静态时序分析，不能替代 STA 或 Gate-Level Timing Check。它的定位是快速观察 Clock Edge 附近的波形状态，并辅助 Gate-Level Simulation Debug。
2.7 查找 Force、Release 和 Deposit
fsdb_find_forces 是非常适合 DV Debug 的能力。在复杂 UVM 环境中，信号行为异常有时并不是 RTL 本身的问题，而是 Virtual Sequence、Error Injection、Backdoor 操作或 Debug Hook 覆盖了 DUT 行为。该工具能够返回事件对应的信号、时间、值和类型，还可以使用 first_force_only 快速查看每个信号第一次被 Force 的时间。
当信号长期保持常量或与 RTL 驱动逻辑不一致时，先排除 Force、Release 和 Deposit，可以显著减少错误方向上的 Debug 时间。
3. 经典应用场景
场景一：Reset 和 Clock Bring-up 检查
Agent 可以检查主 Clock 是否开始翻转、Reset 在何时释放、Reset 前后 Clock 是否稳定、FSM 是否离开初始状态、是否出现 X，以及 Clock Gate 是否按预期打开。
检查这个 FSDB 中 DMA 模块的启动过程。
先定位 clock、reset、enable 和 FSM state。
分析 0 到 20us：确认 Clock、Reset 释放时间、FSM 离开 IDLE 的周期数，
并检查是否存在 Reset 已释放但 Clock 未启动的窗口。
场景二：总线协议握手 Debug
对于 AXI、AHB、APB 或自定义 Request/Response 接口，Agent 可以检查 Request、Valid/Ready、Address、Control、Response、Latency、Backpressure、Timeout 和 Error Response。
分析 150us 到 170us 的 AXI Read Transaction。
检查 ARVALID/ARREADY 和 RVALID/RREADY，确认请求是否被接受、Read Data 是否返回，
并计算 Address Handshake 到第一个 Read Data 的延迟。
场景三：FSM 卡死分析
Agent 可以查询 FSM State，找到最后一次状态转换，检查进入当前状态的输入条件和离开条件，再结合 RTL 状态机逻辑判断是输入条件不满足还是内部逻辑异常。RTL 告诉 Agent 状态应该如何跳转，FSDB 则告诉 Agent 状态实际上如何跳转。
场景四：定位异常信号是否被 Force
当信号长时间保持 0 或 1、与 RTL 驱动逻辑不一致、在异常时间跳变，或者在不同 Testcase 中表现不同，Agent 可以优先调用 fsdb_find_forces，排除 Testbench Override 后再检查 RTL 数据路径。
场景五：围绕 Failure Time 自动收敛
如果 Log 给出 UVM_ERROR at 152340ns，Agent 可以先建立 152240ns 到 152440ns 的小窗口，查询 Error 相关信号、上游 Request、目标模块状态、下游 Response 和 Force 事件。随后按证据扩大或缩小时间窗口，逐步找到最早偏离预期的事件。
| 读取 Failure Log | 提出初始假设 | 查询波形 | 验证或否定 | 追踪上下游 | 形成 Root Cause |
第三部分：在 Claude Code 中安装与使用
1. 从 GitHub 下载并安装
git clone <fsdb-waveform-probe-github-url>
cd fsdb-waveform-probe
uv venv .venv
uv pip install --python .venv/bin/python -e .
安装完成后，可独立启动 Server：
.venv/bin/python -m server
2. 三种使用方式
方式一：直接在 Prompt 中调用
使用 fsdb-waveform-probe 分析以下波形：
FSDB：/path/to/test.fsdb
首先查看 /tb/dut/DMA/* 下的信号，定位 clock、reset、request、ack、interrupt 和 state。
然后分析 100us 到 120us：
1. Reset 何时释放
2. Clock 是否持续翻转
3. Request 是否被接受
4. Response 是否返回
5. Interrupt 是否拉高
6. 是否存在 Force、Release 或 Deposit
7. 给出关键时间点和初步 Root Cause
高质量 Prompt 应明确 FSDB 路径、目标 Hierarchy、时间窗口、已知 Failure Time、关注协议，以及希望回答的问题。
方式二：写入 Skill 的 Validation Step
可以在 DMA Debug Skill 或 Verification Skill 中，将波形查询定义为固定步骤。例如从 Simulation Log 提取第一个 Failure Time，定位 DMA Controller 层级，检查 Clock、Reset、DMA Request、Descriptor、Address、Bus Handshake、Completion、Interrupt 和 Force Event，最后生成带时间证据的 Root Cause Report。
Validation Step 4：
调用 fsdb_get_signals_values 检查 dma_req、dma_ack 和 dma_state。
时间窗口使用 Failure Time 前后各 10us。
如果 dma_req 未拉高，继续检查 enable、reset、descriptor_valid 和 start。
如果 dma_req 已拉高但 dma_ack 未返回，则检查下游 Bus Interface。
方式三：创建专门的 FSDB Waveform Subagent
复杂项目可以创建专门与 FSDB 交互的 Subagent，并只赋予 FSDB Waveform MCP、RTL Search、Simulation Log 读取和必要的设计文档访问能力。
You are an FSDB Waveform Debug Agent.
1. Discover relevant signal hierarchy.
2. Identify clocks, resets, interfaces, states and error signals.
3. Query the smallest useful time window first.
4. Expand the time window only when necessary.
5. Check force, release and deposit before blaming RTL.
6. Correlate waveform evidence with RTL state transitions.
7. Report exact signal names, values and timestamps.
8. Separate observed facts from inferred conclusions.
9. Never claim root cause without waveform or RTL evidence.
主 Agent 可将 DMA Timeout 等任务委派给该 Subagent。波形 Agent 返回 Observed Facts、Inference 和 Recommended Next Check，主 Agent 再把波形证据与 Log、RTL、Specification 和历史问题整合起来。这样既能减少主 Agent 的上下文压力，也便于独立维护波形分析策略和工具权限。
让 Agent 分析波形时应遵循的原则
1. 先探索层级，再查询信号
层级探索链
不要让 Agent 一开始就猜完整 Signal Path。先确认真实层级和命名，再逐步下钻。
2. 优先使用小时间窗口
大型 FSDB 查询可能消耗 CPU、内存、磁盘、NFS 带宽、EDA License 和 Agent Context。如果已有 Failure Time，应先查询其附近的小窗口，只有在证据不足时才逐步向前扩展。
3. 区分事实、推断和结论
Observed Facts：req 在 100ns 拉高，ack 在 500ns 前始终为 0，state 在 110ns 进入 WAIT_ACK。
Inference：状态机正在等待下游响应。
Root Cause 或 Next Step：当前证据只能证明 Response 未返回，需要继续检查下游 Slave 的 Clock、Reset 和 Request 接收状态。
这种分层表达可以避免 Agent 把相关性错误解释为根因。
正确定位是：它让 AI Agent 获得波形调查能力，而不是让 Fsdbreport 取代所有验证和 Signoff 工具。
结语：从「回答问题」到「自主验证」
当 AI 只能阅读文档和 Log 时，它更像一个知识助手。当 AI 可以调用 FSDB MCP 后，它开始具备工程验证能力。
| 读取错误 | 提出假设 | 查询信号 | 验证假设 | 继续追踪 | 收集证据 | 形成结论 |
这意味着 Agent 不再只是回答"这个 Failure 可能是什么原因"，而是可以明确说明它检查了哪些 Reset、Clock、Request、Response、FSM 和 Force Event，最早异常发生在什么时间，以及下一步应追踪哪个上游或下游模块。
波形是芯片运行行为最直接的记录，也是设计验证 Debug 中最重要的事实来源之一。通过 MCP 将 Fsdbreport 封装为标准化工具，我们可以让 Claude Code 或其他 Agent 主动探索 FSDB Hierarchy、查询信号变化、按条件采样、分析时钟边沿，并查找 Force、Release 和 Deposit 事件。
让 Agent 能够「看见」波形，表面上只是增加一项 Tool 能力，实质上却是 AI 从外围辅助走向芯片验证核心工程闭环的重要一步。
