最近参加了 ChipAgents 的一场在线研讨会。整场分享从公司与产品背景讲起，重点介绍了 AI Agent 如何进入数字 IC 设计与验证流程，后半段的问答则集中在几个更实际的问题上：AI 能否处理上万行 RTL、规格是否反而会成为新的工作量、直接生成 RTL 与 HLS 两条路线如何选择、多配置 IP 的 coverage gap 能否自动收敛，以及模拟 IC 是否也能采用类似方法。

这篇文章不是会议逐字稿，而是我根据现场内容整理的技术笔记，并在会后查阅了 Accellera、主流 EDA 厂商、OpenAI、OpenTitan 和 ChipAgents 的公开资料，对研讨会涉及的背景知识作了补充。原始字幕里有一些英文术语被识别成同音词，本文直接按技术语境统一使用 waveform、RTL、UVM、formal verification、counterexample、waiver 等标准写法。

我听完整场分享后，形成的核心认识是：

AI 在芯片研发中的价值，并不只是“生成一段 Verilog”，而是把规格、代码、日志、波形、验证结果和 EDA 工具连接成一个可持续迭代的工程闭环。

通用大模型可以回答硬件问题，也能生成小规模 HDL；但要进入真实项目，仅有模型远远不够。真正决定可用性的，是模型能否理解企业的设计上下文，能否调用仿真、formal、lint、coverage、综合等工具，能否根据结果继续修改，以及整个过程是否可审计、可复现、可由工程师接管。

---

一、先了解 ChipAgents 在做什么

研讨会中介绍，ChipAgents 成立于 2024 年，创始人 William Yang Wang 拥有 Carnegie Mellon University 博士学位，目前也是 UC Santa Barbara 教授。UCSB 的公开个人主页可以确认其 AI、自然语言处理与机器学习研究背景，以及其 ChipAgents 创始人、CEO 身份。¹

公司公开材料显示，ChipAgents 的发展速度较快。2026 年 2 月的融资新闻稿称其累计融资达到 7400 万美元，当时已部署到 80 家半导体公司；2026 年 7 月，公司又宣布追加 6000 万美元融资，并采用 1.34 亿美元的 Series A 总额口径，同时称平台已进入 120 多家半导体公司。Reuters 同期报道采用的累计融资口径约为 1.31 亿美元，并提到公司员工约 64 人。不同来源的统计边界略有差异，因此这些数字更适合作为公司规模和市场进展的背景，而不是精确财务结论。²³⁴

从产品定位看，ChipAgents 并不把自己描述成单一的 RTL 代码生成器，而是一个面向半导体设计与验证的 Agent 平台。研讨会展示的主要能力集中在：

• 规格理解、设计规划与 Spec-to-RTL；
• 既有 RTL 阅读、文档生成、修改与重构；
• 仿真失败分类、日志与波形分析、根因定位；
• 验证计划、testbench、UVM 环境生成与增强；
• formal property、constraint、counterexample 分析；
• code coverage、functional coverage 与 coverage closure；
• RTL 阶段的 PPA 评估，以及未来的 DFT、ECO、APR 等方向；
• 模拟电路 schematic、仿真调优和 AMS behavioral model。

这里最值得关注的，不是某一个功能按钮，而是它试图把多个任务组织成 workflow，再由一个或多个 Agent 协同完成。

---

二、所谓“更懂硬件”，本质上是一套工程系统

研讨会反复强调 ChipAgents 相比 General LLM 更理解 hardware。我的理解是，这里的“懂硬件”不能简单等同于“训练了一个芯片领域模型”，而应拆成六层能力。

规格 / 架构图 / RTL / UVM / Assertion / Log / Waveform / Coverage / EDA Report
                                      │
                                      ▼
                         Parser 与结构化索引
                                      │
                                      ▼
                  项目上下文、领域知识、规则与历史案例
                                      │
                                      ▼
                     Agent Harness 与 Workflow Engine
                                      │
                                      ▼
                    LLM / Domain Model / Multi-Agent
                                      │
                                      ▼
         仿真、Formal、Lint、CDC、Coverage、综合、STA、PPA 等 EDA 工具
                                      │
                                      ▼
                    结果解析 → 修改候选 → 再次验证
                                      │
                                      ▼
                         工程师审查与 Sign-off

1. Parser：让模型真正读懂工程输入

芯片项目的输入不是一段普通文本，而是大量结构化或半结构化资产，例如：

• 数百页规格和微架构文档；
• 跨目录、跨 package、跨 hierarchy 的 SystemVerilog/Verilog；
• 编译日志、仿真日志和 assertion failure；
• FSDB、VCD、VPD 等波形数据库；
• coverage database、formal report、lint/CDC report；
• Tcl、Shell、Python、Makefile、filelist 和 EDA 启动脚本。

如果只是把这些内容全部塞进上下文窗口，模型很快会受到长度、噪声和相关性限制。一个可用的 Agent 平台需要先解析 hierarchy、模块关系、端口、时钟复位、信号依赖、报错位置和波形事件，再把当前任务真正需要的内容交给模型。

ChipAgents 在公开的 RCA 技术文章中也描述了类似思路：不是把完整波形直接交给 LLM，而是在压缩波形上建立结构化索引，让 Agent 能查询 packet、handshake、pipeline stage 和关键时间点。⁵

2. Harness：负责模型与真实工程环境之间的连接

研讨会提到的 harness，可以理解为 Agent 的运行框架。它通常需要处理：

• 上下文选择与长期状态；
• 工具调用和参数生成；
• 文件读取、写入和 diff；
• 命令执行、错误恢复和超时；
• 任务分解与步骤状态；
• 多 Agent 并发；
• 权限、安全沙箱和审计；
• EDA license、计算队列和结果收集。

因此，同一个大模型放在不同 Agent 产品里，实际效果可能差很多。区别往往不只来自 prompt，也来自 harness 是否理解任务、是否能正确调用工具，以及是否能用工具结果纠正模型。

3. Domain knowledge：减少硬件语义漂移

通用模型生成 RTL 时，最常见的问题不是语法完全错误，而是“看起来像硬件，但细节不符合真实微架构”。例如：

• 复位极性、同步/异步复位和复位释放处理错误；
• blocking 与 nonblocking assignment 使用不当；
• 位宽截断、符号扩展和 signed/unsigned 混用；
• valid/ready、backpressure、pipeline latency 对不上；
• X/Z、初始化和四态逻辑处理错误；
• 参数化、generate、interface、package 关系没有完整展开；
• 跨时钟域同步方式不安全；
• 代码可编译，但不可综合或综合结果不符合预期；
• 功能正确，但 PPA、时序或面积完全不可接受。

所以，面向硬件的领域数据、设计规则、代码模式、验证方法和工具经验，确实有机会减少这种语义漂移。ChipAgents 在 2026 年公开了其本地化模型 Renoir，称该模型基于 open-weight MoE 模型进行 fine-tuning，训练数据覆盖 RTL 生成、规格理解、debug、test generation 和 tool use，并面向 on-premises 部署。这里的性能数据仍属于厂商 benchmark，但它至少说明公司正在把领域模型作为整个平台的一层，而不是把所有能力都寄托在单一云端模型上。⁶

4. Workflow：把开放式问答变成可重复流程

直接与模型聊天时，工程师通常要反复补充上下文、纠正方向、要求运行工具，再根据结果继续提问。任务越复杂，越容易发散。

Workflow 的价值，是把任务组织成固定或半固定步骤。例如一个 formal workflow 可以是：

读取 Spec 与 RTL
  → 讨论 property plan
  → 生成 assertion 与 constraint 初稿
  → 编译和 bring-up
  → 调用 formal engine
  → 分类 proof / fail / inconclusive
  → 分析 counterexample
  → 修改 property、constraint 或 RTL
  → 重新运行
  → 生成 proof 与 coverage 报告
  → 工程师审批

这类流程不是简单 prompt 模板，而是包含工具执行、状态判断、分支和回退的任务编排。

5. EDA loop：让工具成为“事实判定器”

研讨会中最重要的一点，是 Agent 并不取代仿真器、formal engine、lint、CDC、综合、STA 或 P&R。AI 可以提出方案、生成代码、选择下一步动作，但最终必须让工程工具回答：

• 能否编译和 elaboration；
• regression 是否通过；
• assertion 是否成立；
• formal 是 proven、failed 还是 inconclusive；
• coverage 是否真实增加；
• 综合后的时序、功耗、面积如何；
• 物理实现后是否存在 congestion、DRC、LVS、IR/EM 等问题。

ChipAgents 自己关于 multi-agent 的文章也把 simulation、formal、STA、synthesis、coverage 和 PPA 称为用于解决争议的 oracle。这个表述比较准确：模型负责提出假设，EDA 工具负责提供证据。⁷

6. Human gate：人仍然负责设计意图和签核

研讨会现场多次提到，Agent 会给出多个候选结论和置信排序，但工程师仍需判断最高分候选是否真的正确。尤其是以下事项，不应由 Agent 无人审批地直接通过：

• 架构和微架构关键决策；
• formal assumption/constraint；
• CDC/RDC waiver；
• coverage exclusion；
• reference model 和 scoreboard 语义；
• PPA trade-off；
• 主干代码合并和 sign-off。

Agent 可以减少搜索和机械劳动，但责任边界不能因为自动化而消失。

---

三、研讨会展示的能力地图

结合演讲内容，我把 ChipAgents 当前和规划中的方向整理成下面这张表。这里的“成熟度”仅表示研讨会中的展示重点，不代表我对产品完成度作独立认证。

领域	研讨会展示的任务	我的理解
规格与架构	规格阅读、需求讨论、模块拆分、plan mode	重点是把隐性设计意图转成可执行任务和验收条件
RTL 设计	Spec-to-RTL、旧 RTL 理解、文档生成、代码修改	适合边界明确的模块和增量修改，仍需完整验证
Debug/RCA	Log、waveform、RTL、testbench 联合分析	是当前最适合 Agent 的场景之一，因为候选可由工具证据验证
Regression triage	大量 error 聚类、重复失败归并、优先级排序	可显著减少人工逐条查看失败日志
Testbench	从 test plan 生成或增强 testbench	适合样板、接口驱动和定向测试，难点在参考模型和 corner case
UVM	从零搭建或增强 UVM 环境	骨架和局部功能较适合生成，环境架构仍需资深 DV 把关
Formal	property plan、SVA、constraint、counterexample debug	能降低使用门槛，但必须防止过约束和 vacuous proof
Coverage	coverage gap 分析、测试增强、UNR 与 waiver 辅助	真正价值是分类、证明、生成 targeted stimulus，而不是只追百分比
PPA	RTL/pre-synthesis 阶段快速估计和优化建议	可减少无效综合迭代，但最终必须回到正式综合和物理实现
DFT/ECO/APR	演讲中列为继续开发方向	AI 更可能作为分析、推荐和闭环编排层，而不是替代 EDA engine
Analog/AMS	schematic、仿真、device tuning、behavioral model、layout prototype	必须依赖 Spectre/SPICE、PVT/Monte Carlo、DRC/LVS/PEX 等 golden flow

这张能力地图也说明，AI4EDA 并不是一个单点产品，而是在逐步覆盖从“语义”到“代码”、再到“工具”和“物理结果”的完整链路。

---

四、从 Spec 开始协作，而不是直接要求 AI 生成整颗芯片

研讨会问答中，一个很有代表性的问题是：如果为了让 AI 生成正确 RTL，需要把规格写得极其详细，那么原来节省的编码时间，会不会只是被转移到了 Spec？

我认为答案不是简单的“会”或“不会”，而是设计工作流正在改变。

1. 过去很多设计决策其实隐藏在代码里

传统项目中，规格往往先描述功能和接口，设计工程师在写 RTL 的过程中继续决定：

• 状态机如何分解；
• FIFO 深度和 backpressure 行为；
• 仲裁优先级和公平性；
• pipeline latency；
• 错误处理、timeout 和 recovery；
• reset 后的状态与寄存器行为；
• 参数配置之间的合法组合。

这些细节可能后来才补回文档，甚至只存在于代码和工程师经验中。

AI 参与后，很多隐性决策需要更早显式化。表面上看，Spec 工作增加了；但如果这些信息同时能用于 RTL、test plan、assertion、coverage 和文档，后续的反复沟通和返工可能会减少。

2. 好的 Spec 不等于无限长的自然语言

面向 AI 的规格不应该只是“写更多文字”，更有效的方法是增加结构化和可执行内容：

• 明确接口表和寄存器表；
• 时序图、状态转换图和 transaction 流程；
• 合法与非法输入；
• latency、throughput 和 ordering 要求；
• reset、interrupt、exception 和 error recovery；
• 参数及配置矩阵；
• assertion skeleton；
• reference model 或伪代码；
• test intent 和验收条件。

研讨会提到 Agent 可以读取常见的硬件时序图，这一点很重要。对于很多协议，图比长篇自然语言更不容易产生歧义。

3. 大设计仍然要拆分

现场也给出了一个比较实际的建议：不要第一次使用 AI 就要求它生成成千上万行、跨多个子系统的完整设计。人类团队本来也会按照 IP、subsystem、module 和接口进行拆分，再分配给不同工程师。

更可行的引入方式是：

1. 先让 Agent 与工程师共同整理某个模块的规格；
2. 让 Agent 输出设计计划和待确认问题；
3. 工程师确认接口、时序和 corner case；
4. 再生成 RTL、testbench 和 assertion；
5. 通过 EDA 工具反复验证；
6. 逐步扩大单个工程师可负责的模块范围。

研讨会用“一个工程师原来负责 5 个 module，熟练后可能扩大到 8 个甚至更多”来说明这种组织变化。我更愿意把它理解为一种渐进式容量扩展思路，而不是一个固定的效率保证。真正能扩大多少，要取决于模块复杂度、已有验证环境、Agent 成功率和 review 成本。

4. 代码行数不是可靠的能力指标

现场有人问，通用模型只能生成一两千行代码，ChipAgents 是否能处理上万行 RTL。讲者回答，客户日常工作中会处理上万行 RTL 的生成和修改。

从工程角度看，“能处理上万行”说明上下文、文件操作和工程规模已经超过教学 demo，但 LOC 本身不能证明质量。一个 1 万行寄存器或胶水逻辑，与一个包含乱序、缓存一致性、复杂流水和多时钟域的 1 万行设计，难度完全不同。

更有意义的评测指标应包括：

• 是否通过 hidden test；
• assertion 和 formal property 是否通过；
• lint、CDC/RDC 是否新增问题；
• 综合结果是否满足 SDC；
• PPA 是否退化；
• 人工修改量和迭代次数；
• 修改后是否引入新的 regression；
• 工程师是否能理解和维护生成的代码。

NVIDIA Research 发布的 VerilogEval 主要用于评测小型 Verilog 生成任务；后续 CVDP 扩展到设计、验证、debug、规格对齐和 Agent 工具调用等多类问题。这些 benchmark 有助于比较模型基础能力，但仍不能代替企业自己的真实 IP 和 sign-off flow。⁸⁹

---

五、直接 Spec-to-RTL，还是先生成 C++/SystemC 再走 HLS

问答中还讨论了两条路线：

路线 A：Spec → RTL
路线 B：Spec → C/C++/SystemC → HLS → RTL

讲者认为两种都可以支持，并提到已有 HLS 流程的客户通常会继续沿用高层综合方法。这与现有 EDA 工具生态是一致的。Cadence Stratus 和 Siemens Catapult 都支持从 C++/SystemC 进行高层综合，再生成 RTL，并在调度、资源分配、流水化和验证环节提供相应工具。¹⁰¹¹

对比维度	Spec → RTL	C/C++/SystemC → HLS → RTL
适合场景	协议控制、寄存器、仲裁、状态机、总线和精细微架构	DSP、图像、通信算法、ML datapath、已有算法模型
控制粒度	可以直接控制 cycle、pipeline 和具体 RTL 结构	通过 directive、constraint、latency、resource sharing 等影响生成结构
主要优势	直接接入现有 RTL 流程，微架构可控	高层算法表达更快，便于架构探索和跨实现重用
主要风险	规格不完整、时序语义错误、代码可读性和 PPA	HLS coding style、directive 选择、生成结构和 PPA 不符合预期
验证重点	RTL testbench、SVA、formal、lint、CDC、synthesis	C/SystemC model、HLS verification、生成 RTL 等价性与下游验证

选择哪条路线不应由 AI 产品决定，而应由模块性质、团队积累、现有 flow 和 PPA 控制要求决定。AI 可以同时参与两条路线，但不能消除原有方法学差异。

---

六、RCA：我认为最接近真实生产价值的场景

整场研讨会中，我最关注的是 RCA，也就是 root cause analysis。

在数字验证里，仿真失败通常只告诉我们“哪里观察到错误”，并不直接说明“错误从哪里开始”。例如最终报错可能是 scoreboard mismatch，但真正根因可能发生在几十或几百个 cycle 之前：某个 pipeline stall 没有正确保持数据，某个 ready 信号早了一拍，或者某个状态在特定 backpressure 条件下发生错误转换。

1. 传统 RCA 的工作链

工程师通常需要：

1. 从日志中提取 failure signature、instance、时间点和 transaction；
2. 打开波形，找到第一处真正偏离预期的位置；
3. 沿 control/data dependency 向上游追踪；
4. 对照 RTL、testbench、reference model、assertion 和 spec；
5. 判断根因属于 DUT、testbench、constraint、初始化、模型还是环境；
6. 修改代码，运行最小复现和 regression；
7. 确认修复没有引入新的问题。

这个过程非常耗费注意力，但它有一个适合 Agent 的特征：根因候选很多，验证一个候选却相对容易。Agent 可以并行探索多个方向，再让日志、波形和仿真结果淘汰错误假设。

2. 研讨会展示的多 Agent 方式

演示中，用户提供 log 和 waveform 的位置，也可以补充 spec、RTL 和已做过的测试。系统会启动多个 Agent，从不同方向寻找根因，并对候选进行排序。运行过程中，工程师还可以通过 steering 提供线索，指导某个 Agent 继续检查特定文件、信号或模块。

找到候选根因后，Agent 不只是解释原因，还可以生成修复、重新运行验证，再确认问题是否消失。

这类“propose → verify → revise”的结构，比单次让模型解释报错更接近真实 debug。

3. 会后查到的公开 RCA 方法

ChipAgents 2025 年发布的 RCA 技术文章进一步说明，其系统包含：

• 为波形建立结构化查询能力；
• 多组 prover–verifier Agent 并行追踪假设；
• 对多个候选进行一致性排序和置信分组；
• 面向批量 regression failure 的异步执行。

该文章公布的内部数据称，其 RCA 在自建数据集上的效果约为领先通用软件 Agent 的 3 倍，并在一个大型 IP 案例中比一名不熟悉该模块的中级工程师快 12 倍。文章同时明确说明，主要测试仍集中在 IP level，subsystem 和 SoC level 更复杂。⁵

这些数字可以作为产品能力线索，但不应直接外推到所有项目。对企业最重要的仍然是用自己的已关闭 bug 做盲测。

4. OpenTitan demo 的意义

研讨会中提到一个 OpenTitan 案例。OpenTitan 是由 lowRISC 管理的开源 silicon root of trust 项目，公开提供 RTL、DV、FPV、lint 和硬件文档，因此很适合展示 Agent 如何读取接近工程规模的设计资产。¹²

它比简单 HDLBits 题目更接近真实项目，但仍与企业私有 SoC 有差异：公开项目的架构、文档和代码都更容易获取，客户项目则可能包含加密 IP、内部脚本、历史包袱和大量非标准 flow。

5. Regression failure 聚类同样重要

现场还提到，如果一次 regression 出现 150 个 error，其中可能有 100 个实际来自同一个根因。AI 可以先按日志模式、调用栈、assertion、层次和波形特征做聚类，再选择代表性失败进行 RCA。

这类任务即使不能完全自动修复，也能明显减少工程师逐条查看的时间。生产环境中，比较理想的输出不是一句“我认为问题在某处”，而是一份可审计的 RCA 包：

• failure signature 和最小复现命令；
• 第一处异常时间点；
• 关键波形和信号依赖；
• 涉及的 hierarchy 与 source location；
• 候选根因、支持证据和反证；
• patch diff；
• patch 前后的仿真、assertion、coverage 和回归结果；
• 尚未确认的风险。

这样，工程师是从“零开始搜索”变成“审查一组有证据的候选结论”。

---

七、UVM：AI 可以搭环境，但验证意图仍然属于工程师

UVM 是基于 SystemVerilog 的标准化验证方法学，相关 API 已纳入 IEEE 1800.2。它的目标是让验证组件模块化、可扩展、可复用，并降低不同项目和工具之间的迁移成本。¹³¹⁴

一个典型 UVM 环境可能包括：

• sequence item / transaction；
• sequence 与 sequencer；
• driver；
• monitor；
• agent；
• environment；
• scoreboard 与 reference model；
• functional coverage collector；
• interface、virtual interface 与 assertion；
• test、virtual sequence 和 configuration；
• UVM RAL、adapter、predictor 和 subscriber。

AI 比较适合完成的工作

• 根据接口定义生成 transaction、driver、monitor 和 agent 骨架；
• 生成 factory registration、phase、port/export/connect 等样板代码；
• 从 test plan 生成 directed 或 constrained-random sequence 初稿；
• 根据编译和仿真日志修复常见连接、配置和 objection 问题；
• 生成寄存器模型接入代码；
• 为现有环境补文档、类关系和 traceability；
• 根据 coverage report 提出测试增强候选。

仍需要资深 DV 决定的工作

• reference model 和 scoreboard 应怎样抽象；
• 乱序、多通道、重放和 backpressure 如何比较；
• stimulus space、约束分布和 corner-case 策略；
• coverage model 是否真正对应规格；
• reset、power state、interrupt、exception 和 error injection；
• IP-level 环境如何复用到 subsystem/SoC；
• simulation、formal、emulation 和 FPGA prototype 如何分工。

因此，研讨会中所说“from scratch 建立完整 UVM environment”，最合理的理解是：Agent 可以加速环境骨架、测试和局部功能的搭建，并在 EDA 工具反馈下迭代；是否已经成为“完整可签核环境”，仍要看 reference model、coverage plan、negative test 和 regression 稳定性。

---

八、Formal Verification：非常适合 Agent，但约束错误会制造假绿灯

Formal verification 是这场研讨会另一个重点。它之所以适合 Agent，是因为很多工作可以被结构化：从规格提取 property、生成 SVA、建立 constraint、运行 proof、读取 counterexample，再根据失败结果继续修改。

1. Formal 的基本流程

Spec
  → Property / Assertion
  → Assumption / Constraint
  → Formal Engine
  → Proven / Failed / Inconclusive
  → Counterexample 或 Proof 信息
  → Debug、分解、补充约束或修改 RTL

Synopsys VC Formal 和 Cadence JasperGold Formal Property Verification 都属于这一类商用平台。官方资料均强调 formal 可以在仿真难以覆盖的状态空间中寻找 corner case；property 不成立时，工具会返回 counterexample，帮助工程师定位失败路径。¹⁵¹⁶

2. Agent 可以明显降低的门槛

• 将自然语言需求转成 SVA 初稿；
• 批量生成 protocol、FIFO、FSM 和 register property；
• 建立 formal testbench skeleton；
• 根据端口和环境提出 assumption 候选；
• 解释 counterexample 中的信号路径；
• 根据 cone of influence、proof depth 和失败原因提出分解策略；
• 整理 property、规格条目和 proof 状态之间的 traceability。

这使得普通 designer 可以先处理一部分局部 formal，formal 专家则聚焦复杂收敛、方法学和 sign-off。

3. 最大风险是 overconstraint

Formal 的危险不只在于 proof 不出来，更在于 proof 看起来成功，但 constraint 把合法输入剪掉了。

例如，Agent 为了让 property 收敛，可能添加一个过强 assumption，使某种真实系统行为永远不能出现。最终工具报告 proven，但证明的只是一个被错误缩小的环境。另一种情况是 assertion 根本没有被有效触发，形成 vacuous proof。

所以，Agent 生成的 constraint 不能自动接受。至少要检查：

• assumption 是否符合真实系统连接；
• 是否存在 overconstraint；
• property 是否被触发；
• reachable state 是否合理；
• constraint coverage 和 vacuity；
• proof core 覆盖了哪些逻辑；
• formal owner 或模块 owner 是否审批。

AI 可以帮助生成 property，也可以帮助解释 counterexample；但 formal sign-off 仍然需要严谨的方法学。

---

九、Coverage：真正困难的是最后一段闭环

现场关于多配置 IP coverage 的提问很有价值。提问者描述，同一套 RTL 可能有十几个配置，汇总后出现上万甚至十万个 code coverage point，最终真正需要处理的可能只剩一百个，其中一部分可由 formal 证明不可达，另一部分需要增加 simulation 激励。

这正是 coverage closure 最耗时的部分。

1. 先区分几类 Coverage

Coverage 类型	回答的问题
Code coverage	RTL 的 statement、branch、condition、toggle、FSM 等是否被执行
Functional coverage	规格定义的功能、组合和 corner case 是否被采样
Assertion coverage	property 是否被触发、成功、失败或 vacuous
Formal coverage	proof 覆盖了哪些目标、哪些点可达或不可达
Requirements coverage	每条需求是否有 test/property/coverage 和结果对应

Code coverage 很高，并不等于 functional coverage 完整；二者都很高，也不等于芯片没有 bug。coverage model 本身可能遗漏需求，testbench 和 DUT 也可能对同一语义产生一致误解。

2. 多配置 IP 的合理自动化流程

我把现场问题进一步展开后，认为一个可靠的 AI coverage workflow 至少应包含：

1. 配置建模：为每个 configuration 记录参数、feature set、合法组合和实例信息；
2. Coverage 规范化：保留 per-config、per-instance 和 union 视图，不能盲目合并；
3. 结构过滤：识别 inactive generate branch、常量传播、配置禁用逻辑和生成代码；
4. Gap 聚类：按 source、逻辑锥、配置条件和可达性特征聚类；
5. Formal UNR：判断长期未命中的点是否真的 unreachable；
6. 可达点分类：区分 constraint 问题、random distribution 问题、缺少 sequence 或 directed test；
7. 生成候选激励：自动生成 targeted test、sequence、constraint patch 或 cover property；
8. 重新运行：比较 coverage delta，同时检查 regression 和 assertion；
9. Waiver 证据：对确认不可达或无需覆盖的点生成证据包，由 owner 审批；
10. 变更失效机制：RTL、参数或 constraint 变化后，旧 waiver 必须重新验证。

Synopsys 的公开资料说明，formal unreachability analysis 可以判断未覆盖目标是否不可达；对可达但难以命中的点，formal cover trace 也可以帮助生成新的 simulation test。VC Formal 的 coverage 结果还可以与 VCS simulation coverage 结合。¹⁷¹⁸

这说明现场提出的“两条路”是合理的：

• 一部分 gap 通过 formal 证明不可达，再形成有证据的 exclusion/waiver；
• 另一部分 gap 通过 simulation 增加测试和激励。

AI 的主要价值，是在海量 coverage point 中完成分类、关联和候选生成，而不是跳过 formal 与 simulation，直接把 coverage 数字改成 100%。

---

十、PPA、综合与后端：AI 更适合减少无效迭代

研讨会中提到，ChipAgents 希望在 pre-synthesis 阶段，根据 PDK 等信息快速估计 RTL 的 PPA，减少“综合后发现结果不好，再回去修改 RTL”的往返。

这个方向本身是合理的。业界已经有 physically aware RTL analysis 和 predictive synthesis 工具，例如 Synopsys RTL Architect 就面向 RTL 阶段的 power、performance、area 和 congestion 预测。¹⁹

但从工程角度看，PPA 校准不可能只依赖 PDK。至少还要考虑：

• standard cell liberty；
• RC tech file；
• memory macro；
• SDC 时钟和 IO constraint；
• UPF/power intent；
• switching activity；
• floorplan、macro 位置和 utilization；
• process/voltage/temperature corner；
• synthesis 与 physical optimization 策略；
• clock tree、routing 和 parasitic 假设。

因此，比较准确的理解是：Agent 可以结合工艺库、约束、历史实现数据和快速预测引擎，对多个 RTL 候选进行方向性排序，只把少数方案送入正式 synthesis、STA 和 P&R flow。

完整数字实现仍然是下面这条链路

RTL
  → Elaboration / Lint / CDC / Formal
  → Logic Synthesis
  → Gate-level Netlist
  → DFT Insertion
  → Floorplan / Placement
  → Clock Tree Synthesis
  → Routing
  → Parasitic Extraction
  → STA / Power / SI / IR / EM / Physical Verification
  → ECO / Sign-off
  → Tape-out

AI 可以分析报告、生成 Tcl、推荐 RTL 变体、定位 timing path 或组织 ECO workflow，但不能替代 golden EDA engine 给出的签核结果。

研讨会也把 DFT、ECO 和 APR 作为继续发展的方向。我认为这些方向要真正落地，最关键的不是模型能否解释概念，而是 Agent 能否在客户的工具版本、PDK、license、LSF/Slurm、目录规范和 sign-off checklist 下稳定执行，并对每一步保留证据。

---

十一、模拟 IC 与 AMS：可以自动探索，但物理真实性不能被跳过

问答中有人特别追问：不是 AMS behavioral model，而是纯模拟 IC 的电路生成、仿真分析和优化是否有方案。

讲者的回答大致描述了这样一条链路：

Spec
  → 讨论电路架构
  → 生成 Schematic
  → 调用 Spectre / SPICE 仿真
  → Device Tuning
  → PVT / 统计分析
  → 设计者反馈
  → 再次调整

从技术上看，这条流程是成立的。Cadence 等 EDA 厂商已经在模拟设计中提供 design centering、optimization、migration 和 layout automation 等能力，AI Agent 可以进一步承担需求整理、仿真编排、结果提取和下一轮参数选择。²⁰

1. PVT 与 Monte Carlo 不能混为一谈

• PVT corner：在离散的 process、voltage、temperature 组合下验证；
• Monte Carlo：对全局工艺变化和器件 mismatch 做统计采样，用于评估分布和 yield。

Agent 可以选择下一批最有信息增益的仿真点，但不能用少量 nominal simulation 代替完整 corner 和统计验证。

2. Behavioral model 是更现实的落地点

研讨会展示得更完整的是 AMS behavioral model workflow。根据需求和用途，可以生成 Verilog-A、Verilog-AMS 或其他抽象模型，再与 transistor-level golden simulation 对比、补充数据并迭代。

Verilog-AMS 是 Accellera 维护的模拟/混合信号行为建模标准。好的 behavioral model 不需要保留全部晶体管内部细节，但必须保持系统集成真正关心的输入输出行为。²¹

ChipAgents 的公开文章把这一过程分为定义范围、生成参考数据、产生模型、对比 golden、迭代修正和部署，并以 PLL、ADC、DAC、LDO 为例说明不同工作区间、PVT、startup、jitter、dropout 和稳定性要求。²²

模型上线前至少要记录：

• 支持的工作模式和输入范围；
• PVT、startup、reset、saturation、lock、dropout 覆盖；
• 与 golden simulation 的误差；
• 未建模物理效应；
• 对应 schematic/netlist 版本；
• 模型的适用场景和禁止使用场景。

3. Analog layout 仍需完整物理验证

即使 Agent 可以生成 layout prototype，也必须继续完成：

• DRC；
• LVS；
• PEX；
• post-layout Spectre simulation；
• matching、symmetry、guard ring、well/substrate 处理；
• EM/IR、可靠性、天线和 ESD 检查。

研讨会本身也把模拟 schematic、device tuning 和 layout generation 描述为仍在 prototype 或持续开发的方向，因此现阶段更适合把它理解为加速探索，而不是自动 sign-off。

---

十二、部署方式：SaaS、On-Prem 与本地模型

研讨会给出了三种大致部署方式。

1. SaaS

最容易开始的是使用云端 SaaS。讲者强调租户隔离、传输加密和 zero data retention，并表示大模型 token 成本包含在平台计费中。

这类方案部署快，但芯片企业不能只听“零留存”口头描述，合同和技术尽调至少要确认：

• RTL、波形、日志、prompt、embedding、cache 和 telemetry 的保留周期；
• 数据是否用于训练、fine-tuning 或人工支持；
• 云区域、subprocessor 和跨境路径；
• backup、灾备副本和删除机制；
• tenant isolation、KMS 和密钥归属；
• Agent 是否可以出网、执行任意命令或访问 secret；
• 管理员访问、审计日志和 incident response。

ChipAgents 于 2026 年 6 月宣布获得 SOC 2 Type II attestation。这个资质可以作为企业安全尽调的一个起点，但 SOC 2 并不自动等同于“所有数据绝对不会保留”，具体仍取决于报告 scope、控制设计、合同和实际部署配置。²³

2. On-Prem

本地部署适合源代码、PDK、波形和调试日志不能离开内网的企业。研讨会提到本地模式会按 seat 计费，并由客户提供 GPU 资源。

对 IC 研发环境来说，本地部署还需要解决：

• GPU 推理集群容量和并发；
• EDA 计算节点、LSF/Slurm queue 和 license feature 配额；
• NFS/并行文件系统上的大量源码和波形访问；
• 容器、依赖包和 EDA 环境初始化；
• 网络隔离、命令 allowlist 和 sandbox；
• 模型、Agent、parser 与 EDA tool 版本兼容；
• 日志、审计、升级、回滚和高可用。

换句话说，On-Prem 不只是“把一个模型放进 GPU 服务器”，而是要把 Agent 安全地接入完整 CAD/EDA 基础设施。

3. 本地模型 refinement

研讨会还提到，可在客户本地选择开源或开放权重模型，再用领域数据进行 refinement。ChipAgents 公开的 Renoir 也被定位为可在客户控制的基础设施上运行的芯片领域模型。⁶

这种方式的优势是数据控制和成本可预测性；难点则是训练数据治理、GPU 资源、模型升级、评测集污染和效果回归。企业必须保留固定 benchmark，确保每次模型更新后，旧任务不出现明显退化。

---

十三、关于 OpenAI 与 Broadcom 的九个月 Tape-out 案例

研讨会接近尾声时，讲者提到一个行业案例：OpenAI 做自己的芯片，并与一家芯片公司合作，在前端导入 AI 后，将完整 tape-out 周期从一年半以上缩短到一年以内。

我会后专门查了这一案例。OpenAI 在 2026 年 6 月公布了与 Broadcom 共同开发的 Jalapeño 推理芯片，并明确写出：

• 该芯片面向 LLM inference；
• OpenAI 与 Broadcom 共同开发；
• 从设计到生产 tape-out 用时九个月；
• OpenAI 的模型参与了设计、实现探索和验证循环。²⁴

OpenAI 后续文章进一步说明，AI 参与了 implementation exploration，缩短了 design、measurement 和 verification loop，并帮助优化部分 arithmetic circuit。²⁵

因此，这个案例可以在文章中写成：

OpenAI 与 Broadcom 共同开发了面向大语言模型推理的 Jalapeño 芯片。OpenAI 官方称，该项目从初始设计到 manufacturing tape-out 用时九个月，并使用 OpenAI 模型加速部分实现探索、设计、测量和验证循环。

但有两点需要保持准确：

1. OpenAI 的公开材料没有给出“原本需要一年半以上”的同口径 baseline，因此不能确定地写成“从 1.5 年缩短到 9 个月”；
2. 公开资料没有显示 ChipAgents 参与了该项目，它是研讨会引用的行业案例，不是 ChipAgents 客户案例。

这个案例真正说明的是：当一家组织同时掌握模型、工作负载、架构、编译栈和芯片实现闭环时，AI 已经能够进入真实 ASIC 项目的设计和验证过程。但它不能证明所有芯片项目都能在九个月内完成，也不能证明任意通用 Agent 都能复制同样结果。

---

十四、我对 AI4EDA 落地方式的几点判断

1. 最先落地的不是“无人设计”，而是高频迭代自动化

现阶段最容易形成稳定收益的任务，通常具有三个特征：

• 人工耗时高；
• 输入和输出相对明确；
• 结果可以由工具验证。

RCA、regression triage、UVM 样板、formal property 初稿、coverage gap 分类和报告分析都符合这一条件。

2. AI 不会替代 EDA，反而更依赖 EDA

Agent 越自动化，就越需要可靠的 simulator、formal engine、lint/CDC、synthesis、STA 和 P&R 作为反馈来源。没有这些工具，Agent 很容易停留在“语言上合理”。

3. 工程师的工作会从编写转向定义、审查和编排

研讨会提出，希望让 150 名工程师完成过去需要更大团队才能完成的工作。这个目标是否能够实现，需要客户自己的数据证明；但角色变化的方向是清晰的：

• 更早把需求和微架构说清楚；
• 审查 Agent 的计划和假设；
• 定义验证边界和签核标准；
• 评估多个候选实现；
• 管理跨 design、DV、formal、PPA 和 DFT 的 workflow。

AI 更可能先减少“搬砖式”的搜索、样板代码和重复迭代，而不是立即消除设计和验证岗位。

4. 企业必须用自己的历史任务做 PoC

我认为最有代表性的 PoC 不应是现场生成一万行 RTL，而应选择已有标准答案的真实任务：

• 20～50 个已关闭的仿真 bug，用于评估 RCA Top-1/Top-3、误修率和人工触达时间；
• 一个现有 UVM 环境，增加新 feature、sequence、checker 和 coverage；
• 一个中等复杂度 block，建立 formal plan、property、constraint 和 proof；
• 一个多配置 IP，对真实 coverage gap 做 UNR、targeted test 和 waiver；
• 一个边界清晰的 RTL 模块，比较生成前后的功能、lint、CDC、synthesis 和 PPA。

评测时要固定 RTL commit、spec、EDA tool/hotfix、PDK/library、SDC 和计算资源，并记录所有人工提示、重试、token、GPU、license 和 wall-clock 成本。

5. 自动化权限必须逐级开放

比较安全的落地顺序是：

只读分析
  → 在临时 Workspace 生成候选 Patch
  → 允许提交受限 EDA Job
  → 自动生成 Merge Request
  → 由 CI 与 Owner 审批
  → 仅对成熟低风险 Workflow 开启自动触发

不建议让 Agent 自动批准 formal constraint、CDC waiver、coverage exclusion、主干合并或 tape-out sign-off。

---

十五、我的会议总结

这场研讨会让我更清楚地看到，芯片领域的 AI Agent 与普通代码助手之间，真正的差异不在于能否回答 Verilog 问题，而在于是否具备面向硬件的输入解析、领域知识、workflow、EDA tool use 和结果验证能力。

通用 LLM 在没有企业项目上下文和工具闭环时，容易在时钟、复位、位宽、并发、协议、波形和跨文件关系上产生语义漂移。ChipAgents 试图通过领域数据、规则、parser、Agent harness、自有或第三方模型，以及 simulator/formal/synthesis 等工具反馈，减少无效 iteration。这里真正有价值的不是“模型说得更像工程师”，而是它能否持续拿出可验证证据。

在当前阶段，RCA、regression triage、UVM、formal 和 coverage 是较有现实意义的应用。它们都包含大量重复、耗时但可以被工具验证的工作。AI 可以先做搜索、分类、样板生成、候选修复和结果整理，工程师则负责规格、约束、corner case、证据判断和 sign-off。

Spec-to-RTL 也不会简单变成“一句话生成芯片”。更可能的工作方式，是工程师从 spec 开始与 AI cowork，把设计逐步拆成可执行、可验证的模块。随着 Agent 的稳定性提高，一个工程师可能逐渐覆盖更多 module；但这种效率提升必须建立在 review 成本没有同步失控的基础上。

对于 PPA、DFT、ECO、APR 和模拟 IC，Agent 的作用更可能是组织探索、解释报告、生成候选并驱动 EDA 闭环。最终的物理真实性和签核结果，仍然来自正式工具、PDK、约束和工程方法学。

OpenAI 与 Broadcom 的九个月 tape-out 案例说明，AI 已经可以进入真实芯片开发流程；但公开信息只能支持“九个月完成从设计到 tape-out，并由 OpenAI 模型加速部分环节”，不能进一步写成“ChipAgents 将 OpenAI 项目从一年半缩短到九个月”。

综合来看，我认为 ChipAgents 代表的是 AI4EDA 的一个重要方向：不再把 AI 只放在聊天窗口里，而是让它成为连接设计意图、工程资产和 EDA 工具的执行层。它是否能在某一家企业产生 30%、50% 或更高的效率提升，最终仍要由真实项目、内部 benchmark 和可审计的工程结果回答。

---

参考资料

1. UC Santa Barbara, William Wang — Academic Profile, accessed 2026-08-31. ↩︎

2. Business Wire, ChipAgents Raises $74M to Scale an Agentic AI Platform to Accelerate Chip Design, 2026-02-17. ↩︎

3. ChipAgents, Newsroom, accessed 2026-08-31. ↩︎

4. Reuters, Nvidia partner ChipAgents raises $60 million to accelerate chip design with AI agents, 2026-07-29. ↩︎

5. ChipAgents, ChipAgents RCA: Autonomous ASIC Root Cause Analysis, 2025-11-05. ↩︎ ↩︎²

6. ChipAgents, Introducing Renoir, ChipAgents’ First Model, 2026-06-17. ↩︎ ↩︎²

7. ChipAgents, Multi-Agent Debate in AI for Chip Design & Verification, 2025-09-23. ↩︎

8. NVIDIA Research, VerilogEval: Evaluating Large Language Models for Verilog Code Generation, ICCAD 2023. ↩︎

9. Pinckney et al., Comprehensive Verilog Design Problems: A Next-Generation Benchmark Dataset for Evaluating Large Language Models and Agents on RTL Design and Verification, 2025. ↩︎

10. Cadence, Stratus High-Level Synthesis, accessed 2026-08-31. ↩︎

11. Siemens EDA, Catapult High-Level Synthesis & Verification, accessed 2026-08-31. ↩︎

12. lowRISC / OpenTitan, OpenTitan: Open Source Silicon Root of Trust and Hardware Documentation, accessed 2026-08-31. ↩︎

13. Accellera, Universal Verification Methodology Working Group, accessed 2026-08-31. ↩︎

14. Accellera, UVM Reference Implementation Aligned with IEEE 1800.2-2020, 2020-12-16. ↩︎

15. Synopsys, VC Formal: Formal Verification Solution, accessed 2026-08-31. ↩︎

16. Cadence, JasperGold Formal Property Verification, accessed 2026-08-31. ↩︎

17. Synopsys, How Formal Verification Tools Enhance SoC Simulation Coverage Closure, 2022-11-20. ↩︎

18. Synopsys, Streamline Projects with Verdi and VCS Coverage Tools, 2023-07-12. ↩︎

19. Synopsys, RTL Architect: Physically-Aware RTL Analysis, accessed 2026-08-31. ↩︎

20. Cadence, AI in Analog Design, accessed 2026-08-31. ↩︎

21. Accellera, Verilog-AMS Standard, accessed 2026-08-31. ↩︎

22. ChipAgents, Why Chip Engineers Should Care About AI-Created Behavioral Models, 2026-06-05. ↩︎

23. ChipAgents, Trusted Agentic AI for Semiconductor Engineering: ChipAgents Achieves SOC 2 Type II Attestation, 2026-06-18. ↩︎

24. OpenAI, OpenAI and Broadcom Unveil LLM-Optimized Inference Chip, 2026-06-24. ↩︎

25. OpenAI, Jalapeño’s First Results Show Industry-Leading Speed and Efficiency in AI Inference, 2026. ↩︎