【AI for EDA】基于 LLM 的 UPF 自动生成：从 SpecVision 到 BusForge
基于 LLM 的 UPF 自动生成：从 SpecVision 到 BusForge
关键词：LLM、UPF、AI for EDA、低功耗验证、RAG、Agent、SpecVision、BusForge、Power Intent 自动生成
适合人群：关注 AI+EDA 交叉方向的研究者、想了解 LLM 如何落地硬件验证的工程师
系列前文：《VCS NLP 低功耗验证全攻略》《UVM 低功耗验证环境搭建》《JasperGold LP App 形式化验证实战》
📖 前言：贯穿全系列的那个"地基问题"
回顾这个系列的前三篇：
- 第一篇用VCS NLP做仿真验证
- 第二篇用UVM搭建工程化的低功耗验证环境
- 第三篇用JasperGold LP App做形式化证明
三篇文章，三种方法，但它们都建立在同一个前提之上——
一份正确的 UPF 文件。
而 UPF 是什么状态？几百上千行 TCL，由工程师逐行手写，信息来源散落在：规格书的功耗章节、电源管理框图、PST 表格、IP 集成手册、口头约定……一个clamp_value写反、一个 instance 漏进 domain、一条跨域线忘了声明 LS——前面三篇所有精密的验证，地基就歪了。
更尴尬的是：我们花大力气验证的，可能只是"UPF 写得对不对"，而不是"设计本身对不对"。
那么一个自然的问题浮现：能不能让 LLM 来生成 UPF？能不能直接从规格文档，自动产出 power intent？
本文不是一篇"工具教程"，而是一篇研究方向的梳理——介绍一个面向该问题的研究框架，及其中的两个核心组件：SpecVision和BusForge。
一、为什么 UPF 生成是个"好问题"？
判断一个 AI for EDA 课题值不值得做，可以看三个维度：
| 维度 | UPF 自动生成的情况 |
|---|---|
| 痛点真实 | UPF 手写易错、跨团队信息不对齐，是公认的工程痛点 ✅ |
| 结构化程度 | UPF 是受 IEEE 1801 标准约束的形式语言，语法明确、可机器校验 ✅ |
| 可验证 | 生成结果能被 JasperGold/VCS NLP客观判对错，不像自然语言生成那样难评估 ✅ |
第三点尤其关键。LLM 最大的问题是"幻觉"——它可能一本正经地胡说。但在 UPF 生成这个场景里，我们有现成的"判官"：上一篇的 JasperGold 结构检查能秒级判断生成的 UPF 拓扑对不对。这意味着 LLM 的输出可以被闭环校验，这是 UPF 生成区别于很多 LLM 应用的根本优势。
二、整体愿景：一个 LLM 驱动的 Power Intent 生成框架
把"从规格到 UPF"这条链路拆开，整体框架长这样：
输入 处理流水线 输出 + 闭环 ┌──────────┐ ┌─────────────────────────────┐ ┌──────────────┐ │ 规格文档 │ │ ① SpecVision │ │ │ │ (PDF/图) │───►│ 多模态电源意图抽取 │───►│ 结构化 │ │ │ │ │ │ Power Intent │ │ 设计框图 │ │ ② BusForge │ │ (中间表示 IR)│ │ │───►│ 接口/总线感知的意图补全 │───►│ │ │ RTL 接口 │ │ │ └──────┬───────┘ └──────────┘ │ ③ UPF Generator │ │ │ IR → 标准 UPF (IEEE 1801)│◄──────────┘ └──────────────┬──────────────┘ │ 生成的 UPF ▼ ┌─────────────────────────────┐ │ ④ 验证闭环 (Closed-Loop) │ │ JasperGold 结构检查 │ │ + VCS NLP 仿真反馈 │ │ + 覆盖率驱动的迭代修正 │ └──────────────┬──────────────┘ │ 错误/反例反馈 └──────► 回到 ②③ 重新修正这个框架有三个设计原则：
- 不让 LLM 一步到位——规格 → UPF 跨度太大，拆成"抽取意图 → 补全意图 → 生成语法"三步
- 用中间表示（IR）解耦——LLM 负责生成结构化 IR，UPF 语法由确定性的模板引擎渲染，降低幻觉
- 闭环而非开环——生成的 UPF 必须经过验证工具反馈，错了就带着错误信息重新生成
下面重点讲 ① 和 ②。
三、SpecVision：从规格文档中"看懂"电源意图
3.1 要解决什么
电源意图的源头是规格文档，但这些信息不是纯文本：
- 文字描述