作者:电子创新网张国斌

过去几十年,EDA行业的核心逻辑并没有发生根本变化。工程师提出设计需求,使用EDA工具完成建模、设计、综合、仿真、验证、布局布线,最终经过一系列严格的验证流程完成Tape-out。
工具越来越强,芯片越来越复杂,但“人操作工具”依然是整个流程的基本范式。
但AI的出现正在打破这一点。尤其是大模型推理能力快速提升之后,EDA开始从“工程师使用工具”,逐渐走向“Agent调用工具”。但一个值得注意的变化是:当AI进入EDA之后,真正被改变的可能并不是芯片设计本身,而是设计、验证和优化之间的力量关系。

芯华章科技研发副总裁刘军
近日,芯华章科技研发副总裁刘军接受电子创新网独家专访时,他指出AI可以让设计生成变得越来越容易,但验证不会因此变得便宜。恰恰相反,随着AI能够生成越来越多的代码,验证和优化的重要性还会进一步上升。这也是芯华章正在推进Agentic EDA的核心逻辑。
他表示真正的Agentic EDA,是让AI从过去的“辅助工具”,进一步成为能够理解设计意图、规划任务、调用工具、分析结果、迭代执行的智能体。这意味着,未来工程师面对的可能不再是一堆需要逐一操作的EDA工具,而是一套能够自主执行大量工作的Agent系统。
但问题也随之而来:如果AI可以越来越快地产生RTL代码,谁来证明这些代码是对的?
如果AI可以在几分钟甚至几秒钟内生成大量设计方案,谁来保证它们满足PPA要求?如果一个Agent自主运行数小时甚至更长时间,它给出的结果又如何让工程师相信?
在芯华章看来,这恰恰是AI进入EDA之后最值得关注的变化。AI EDA真正的核心,不只是“让AI做设计”,而是建立一套能够让AI生成结果被验证、被追溯、最终被签核的体系。
从“AI辅助EDA”到“Agentic EDA”,变化的不只是工具
2025年以来,AI EDA开始明显升温。Synopsys、Cadence、西门子EDA以及国内EDA厂商都在推进AI与传统EDA工具的融合。
在刘军看来,Agentic EDA与传统EDA之间存在一个非常重要的区别。传统EDA的基本逻辑是:人 → 工具 → 结果。工程师需要理解工具、学习命令、搭建流程,然后一步步完成设计或者验证任务。而Agentic EDA正在变成:人 → Agent → 多个EDA工具 → 结果 → 反馈 → 再执行。
其中,大模型承担的是推理和任务规划;Agent负责拆解任务、调用工具、理解结果并进行下一步决策;而真正产生确定性结果的,依然是底层EDA工具。
他指出这一区别非常关键。因为在芯片领域,“会生成”并不等于“能签核”。大模型本质上仍然具有概率生成属性。无论模型能力多强,它都可能出现幻觉、上下文丢失或者生成不可复现结果的问题。对于普通的软件开发,这些问题可能只是增加调试成本。但对于芯片设计,尤其是承担最终Sign-off职责的验证环节,这种不确定性是不能直接接受的。
所以,Agentic EDA并不是要把传统EDA扔掉。恰恰相反,传统EDA工具的重要性反而被重新定义了。过去,工程师直接使用EDA工具。未来,可能更多是Agent调用EDA工具。EDA工具从“工程师的操作界面”,逐渐变成Agent背后的确定性执行引擎。
大模型负责“想”,EDA工具负责“证明”
刘军指出这是理解AI EDA最关键的一点。大模型最大的优势,是处理非结构化信息和复杂任务推理。例如面对一个验证任务,Agent可以理解Specification,拆解验证目标,选择合适的方法学,然后调用Simulation、Formal Verification、Debug等不同工具。
但当它需要回答:“这个设计到底对不对?”最终不能靠大模型自己回答。必须回到底层EDA工具。因为EDA工具的一个重要价值,就是它能够给出确定性的结果和证据。
这也解释了为什么芯华章并没有把AI EDA理解成“用大模型替代EDA”。芯华章正在推进的X-IVS(Intelligent Verification System),本质上就是在已有验证工具体系之上增加智能化能力。Simulation Agent、Debug Agent、Formal Agent并不是独立存在的聊天机器人,而是建立在原有EDA工具之上的智能层。
这实际上形成了一个新的架构:大模型负责推理,Agent负责调度,EDA工具负责执行,验证结果负责证明。这个体系甚至可以被进一步概括为:AI负责效率,EDA负责确定性,人负责最终判断。
这可能是未来Agentic EDA非常重要的一条边界。
为什么“可信AI”比“更强AI”更重要?
AI进入EDA之后,最大的挑战可能并不是模型参数规模,而是“可信性”。原因很简单。芯片验证不是一个“参考答案大概正确”就可以接受的领域。验证工程师最终要面对的是Sign-off。
因此,刘军特别强调一个概念:可信AI(Verified AI)。这里的“可信”,并不是说模型永远不会犯错。而是即使AI参与了整个过程,也必须能够回答:AI做了什么?为什么这么做?调用了哪些工具?使用了哪些输入?中间产生了什么结果?哪一步出现了异常?最终结论依据是什么?工程师能不能重新检查?整个过程能不能复现?
这实际上要求Agentic EDA建立一条完整的Evidence Chain——证据链。也就是说,Agent不能只给工程师一个“验证通过”。它必须告诉工程师:为什么通过?甚至当Agent发现问题时,也不能简单地说:“这里有Bug。”而应该给出:“这是一个Suspect。”即一个“怀疑对象”。
因为大模型发现的问题,本身仍然属于概率性判断。最终是否构成确定性的Bug,依然需要通过确定性的EDA工具以及工程师进行确认。这就形成了一种非常特殊的人机关系:“AI负责发现问题,人负责确认问题。”
Verification不会被AI削弱,反而可能越来越重要
这可能是AI EDA带来的一个反直觉变化。很多人原本认为:既然AI能够自动生成RTL、自动产生测试用例、自动做Debug,那么验证工程师是不是会越来越少?
刘军给出的判断恰恰相反。原因在于:设计生成正在变得越来越容易,但设计验证依然昂贵。AI可以快速生成代码,但它无法天然保证代码正确。AI可以快速产生大量设计方案,但也会产生更多需要验证的内容。
于是,一个新的矛盾出现了:设计生成速度正在超过验证能力。过去,一个工程师可能花一天写一段RTL。未来,设计生成Agent可能在很短时间内生成大量RTL。但这些RTL仍然需要进行Simulation、Formal Verification、Coverage分析、Debug以及Sign-off。
于是,验证反而成为AI时代需要重点补强的环节。从这个角度看,AI EDA并不是让验证消失,而是在帮助验证工程师追赶和弥补AI带来的设计生成速度和设计验证速度之间日益扩大的差距。
这也是为什么芯华章将验证和优化视为AI时代两个会被进一步放大的方向。设计生成解决的是:“能不能做出来?”而验证解决的是:“到底对不对?”优化解决的则是:“能不能做得更好?”而后两个问题,恰恰不会因为AI生成能力增强而自动消失。
Simulation、Debug、Formal:Agent正在重新组织验证流程
刘军表示从具体技术来看,芯华章目前已经将AI能力嵌入Simulation、Debug和Formal Verification等环节。以Simulation Agent为例。传统验证流程中,工程师需要设计大量Test Case,并通过Coverage不断判断验证是否充分。AI加入之后,可以根据当前Coverage情况产生针对性的测试激励。
也就是说:Coverage不再只是验证结果,也可以成为Agent下一步行动的反馈信号。Agent可以根据Coverage缺口,进一步生成测试场景,再运行Simulation,然后重新分析Coverage。
由此形成:测试生成 → 仿真 → Coverage → 分析缺口 → 再生成测试 → 再仿真的闭环。这与过去依赖工程师不断手工补充Test Case的方式相比,最大的变化不是“AI写代码”,而是验证流程开始具备自主迭代能力。
刘军指出Debug Agent解决的则是另外一个长期困扰验证工程师的问题。一次回归测试可能产生数百、数千甚至更多失败用例。过去工程师需要逐个查看。传统脚本可以根据日志做一些简单的过滤和归类,但面对复杂的上下文关系和非结构化数据,能力有限。
大模型则可以进一步进行:失败用例分类 → 关联分析 → Root Cause定位 → Suspect提取。最终工程师面对的不再是几千个孤立的失败用例,而可能是一组经过归类后的Root Cause。
这相当于把验证工程师从“逐条看日志”的工作中解放出来。
而Formal Agent则更加值得关注。Formal Verification过去一直存在较高的使用门槛,其中一个重要问题就是SVA断言语言的编写。他表示芯华章已经在这一方向上进行较早探索,包括利用模型微调以及Skill沉淀,提高断言生成能力。但真正重要的并不是“AI能生成多少条SVA”。而是:“这些SVA是否与原始Specification一致?是否真正覆盖设计意图?”因此,芯华章的Formal Agent并不是生成断言后就结束,而是增加了针对Specification一致性的检查,并在最终验证阶段收集Coverage。
包括Cone of Influence等指标以及验证Coverage,都需要回到传统Formal Verification体系进行确定性判断。换句话说:AI可以生成验证逻辑,但最终是否有效,必须由Formal工具来证明。
从“自然语言→RTL”到“自然语言→C→RTL”,设计范式正在改变
如果说验证是AI EDA最先成熟的突破口,那么设计侧的变化可能更加激进。今天已经有不少公司在尝试让大模型直接根据自然语言生成RTL。看起来非常诱人:自然语言 → RTL → 芯片。
但芯华章在实际探索中发现,至少在当前阶段,这种路径存在一个重要问题:PPA并不理想。原因在于RTL并不是简单的代码。同一个功能,可以有完全不同的硬件实现方式。AI生成的RTL即使功能正确,也不意味着面积、性能和功耗最优。
因此,刘军指出芯华章在X-IDS智能设计系统中探索了一条不同路径:自然语言 → 算法/C模型 → RTL。为什么要多这一层?
因为C模型更适合描述算法。算法工程师可以在C层面进行算法表达、架构探索和优化,然后再由后续Agent把C模型转换为RTL。
这实际上是在自然语言与硬件实现之间增加了一层算法设计中间表示。它的意义不仅是改善PPA。更重要的是,它为AI设计过程留下了一个中间状态。如果未来工程师需要追溯:
“为什么AI最后产生了这个RTL?”那么他可以沿着需求 → C模型 → 算法 → RTL
链路追踪。这其实又回到了前面提到的“证据链”。
因此,芯华章并不认为“自然语言直接生成RTL”一定是最终答案。真正值得关注的,可能是:AI正在重新定义芯片设计的中间表示和工作流。这也意味着,传统RTL设计工程师的价值正在发生迁移。算法工程师、架构师、设计工程师之间的边界也可能因此发生变化。最终形成的可能是:算法设计 → 架构探索 → PPA评估 → 硬件实现的一体化流程。所以AI真正降低的,并不是芯片设计本身的难度,而是操作复杂工具的门槛。工程师则越来越需要把精力放在架构、算法和系统层面。
此外,AI时代,PPA优化可能成为另一个超级战场,刘军表示未来Agent可能不断尝试:生成设计 → 综合 → PPA评估 → 修改 → 再综合 → 再评估。最终形成一个自动优化循环。工程师不需要再亲自尝试几百种方案。Agent可以做。但最终依然需要EDA工具告诉它:哪一个方案在真实的硬件约束下更好。因此,AI与EDA结合之后,“优化”很可能和“验证”一样成为核心能力。
到了这里,一个很重要的问题浮现出来:如果大家都能接入大模型,Agentic EDA最终比拼什么?模型参数?刘军表示答案是未必--因为基础模型正在快速同质化。真正难复制的,很可能是EDA厂商长期积累的:工具 + 方法学 + 数据 + Skill + 工程经验 + 验证体系。
尤其是最后的“可信闭环”。一个真正面向芯片设计的Agent,需要处理长上下文,需要理解复杂EDA流程,需要知道什么时候调用Simulation,什么时候调用Formal,什么时候进入Debug,还需要保存完整运行轨迹和证据文件。
国产EDA的一个特殊窗口期正在出现
刘军认为,AI时代的EDA实际上给国产厂商提供了一次相对平等的机会。尤其是国内EDA企业的研发团队、客户以及上下游合作伙伴都在国内,在大模型、推理框架、AI基础设施快速发展的背景下,本土厂商可以更加紧密地与国内AI产业链协同。
但这并不意味着国产EDA只要接入一个大模型就能赢。恰恰相反。他指出AI EDA会让EDA行业的“生态属性”进一步增强。未来一套完整的Agentic EDA系统,很难只依靠一家企业完成。它需要:EDA厂商 + 大模型厂商 + GPU/算力厂商 + 推理基础设施 + IP厂商 + 芯片设计企业共同构建。因此,下一阶段国产EDA真正需要补的,可能不只是某一个工具,而是整个生态。
他同时指出生态化之后,一个现实问题会越来越突出:不同厂商的Agent怎么协同?假设一家芯片公司前端设计使用A厂商工具,Formal使用B厂商工具,Simulation使用C厂商工具。过去,这些工具虽然存在数据交换问题,但工程师最终可以通过传统流程把它们串起来。
Agent化之后,问题会更加复杂。因为工程师可能同时调用多个Agent。这时候一个核心问题就是:如何统一衡量整个验证过程到底完成到了什么程度?这也是统一覆盖率的重要性所在。
刘军表示未来可能是多个Agent协同调用不同EDA工具,自动完成大量设计、验证和优化任务。但最终仍然需要工程师理解架构、定义目标、审查证据并完成Sign-off。这意味着芯片设计的价值链正在发生迁移。设计生成越来越容易,验证越来越重要;工具操作越来越自动化,架构和优化越来越重要;单点工具越来越智能,生态协同越来越重要。
所以,Agentic EDA真正值得关注的,并不是“AI什么时候能够一键生成芯片”。更现实的问题是:当AI可以无限生成设计之后,谁能够最快、最可靠地证明这些设计是对的,并把它优化到足够好的PPA?
这可能才是下一阶段EDA真正的竞争高地。而这也是芯华章押注AI EDA之后,试图回答的问题。
对此大家怎么看?欢迎留言讨论!
特别通知:在10月19日召开RISCV-V中国峰会上,芯华章将举办Agentic EDA数字流程解决方案研讨会欢迎扫码报名!

注:本文为原创文章,未经作者授权严禁转载或部分摘录切割使用,否则我们将保留侵权追诉的权利。