企业官网建设流程全解析

基于 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 课题值不值得做，可以看三个维度：

第三点尤其关键。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 仿真反馈 │ │ + 覆盖率驱动的迭代修正 │ └──────────────┬──────────────┘ │ 错误/反例反馈 └──────► 回到 ②③ 重新修正

这个框架有三个设计原则：

1. 不让 LLM 一步到位——规格 → UPF 跨度太大，拆成"抽取意图 → 补全意图 → 生成语法"三步
2. 用中间表示（IR）解耦——LLM 负责生成结构化 IR，UPF 语法由确定性的模板引擎渲染，降低幻觉
3. 闭环而非开环——生成的 UPF 必须经过验证工具反馈，错了就带着错误信息重新生成

下面重点讲 ① 和 ②。

三、SpecVision：从规格文档中"看懂"电源意图

3.1 要解决什么

电源意图的源头是规格文档，但这些信息不是纯文本：

• 文字描述