模拟电路设计大概是芯片研发流程里“最吃经验、最难自动化”的环节拓扑结构靠资深工程师拍板尺寸参数靠多年积累的直觉加反复仿真迭代。AaLLM 这个框架要做的就是把这套流程从给定设计指标开始交给大语言模型一路走到电路尺寸收敛形成一条端到端链路拓扑生成、网表落地、仿真反馈、参数整形。从项目标题可以拆出三个关键点第一它不是单点工具而是完整流程框架第二它把“拓扑生成”和“sizing”两件模拟设计最难的事串在一起第三底层引擎是大语言模型说明设计约束、电路结构、修改建议都会以文本形式进入模型。换句话说AaLLM 的逻辑是“模拟电路设计在语言层面有大量结构信息LLM 完全有条件当设计助手”。这篇文章会先给 AaLLM 的能力速览和适用边界然后把它的端到端流程拆成规格输入、拓扑生成、网表校验、尺寸寻优、仿真验证几个环节最后落到一套可执行的本地验证方法上环境准备、最小实验配置、批量任务、接口接入、资源占用和问题排查。看完你可以直接照着搭一套“LLM 先生成拓扑仿真器再打分”的模拟设计验证链路等 AaLLM 论文开源后也能快速迁移到它的实现上。1. AaLLM 核心能力速览以下能力表按项目定位整理。由于输入材料主要来自标题和关键词部分参数需要以论文正式版本或开源仓库为准建议以“先通读链路再对实现细节”的方式阅读。能力项说明项目定位AI4EDA 领域的研究型框架面向模拟电路自动设计流程覆盖从设计规格到拓扑生成再到器件尺寸sizing的端到端链路核心输入设计规格文本或结构化指标例如增益、带宽、相位裕度、功耗约束核心输出候选拓扑 / SPICE 网表 / 尺寸设计 / 迭代修改建议底层引擎大语言模型负责结构推理、网表生成和迭代分析配套验证外部电路仿真器如 ngspice、Spectre、HSPICE本地部署门槛取决于所选 LLM 尺寸使用 API 服务时本机不强制需要 GPU批量任务从框架的设计目标看天然适合规格批量探索需要自行封装任务队列接口能力取决于是否将模型封装为 API 服务可用 OpenAI 兼容协议或 vLLM 等方式接入适合读者模拟 IC 工程师、EDA 工具开发者、AI4EDA 研究者、做自动验证流程的团队这里要强调的是AaLLM 和市面上常见的“LLM 画版图”“LLM 补注释”不是一回事。画版图和补注释属于辅助提效AaLLM 的定位是端到端给规格出候选电路结构再在仿真反馈下把尺寸调到达标。模拟设计的两个核心瓶颈它都试图用 LLM 去覆盖。2. 从模拟设计流程看 AaLLM 的建模目标2.1 拓扑生成把经验判断转成语言生成模拟设计的第一个难点是拓扑。同样是做一个运算放大器可以用单级差分放大器、折叠共源共栅结构、两级 Miller 补偿结构还可以在输出级加 Class AB 驱动。不同拓扑对应的增益、摆率、噪声、电源抑制和面积表现差别很大选错结构后面再怎么调尺寸都没用。过去拓扑靠工程师头脑里的“设计案例库”。LLM 在这里的优势恰恰是它在海量论文、教科书、设计笔记和公开网表上做过预训练能根据规定指标联想到若干候选结构。AaLLM 这类框架通常会让 LLM 输出结构化内容先给电路类型和设计目标再让它生成具体节点连接关系最后落成 SPICE 网表。这个过程的重点不是“生成一个能跑的网表”而是让它生成多个有差异、有代表性的候选拓扑覆盖设计空间。2.2 Sizing一个带仿真反馈的迭代优化问题拓扑给定后下一步是把电路里每个 MOS 管的沟道长度、沟道宽度、指数和偏置电流确定下来在高增益、高带宽、低功耗、低噪声和小面积之间折中。这就是标题中的 sizing。sizing 的本质是高维参数寻优而且很多目标互相矛盾加大偏置电流能提带宽但功耗会超标增大输出管尺寸能降低噪声但节点电容变大、带宽又掉下去。传统做法是手动扫描加经验公式估算再让仿真器帮你看结果。AaLLM 要做的是让 LLM 参与这个闭环模型先给一组尺寸仿真器跑完后把指标偏差返回给模型模型根据偏差调整下一轮尺寸。这个“生成-仿真-反馈-再生成”的循环比单纯让 LLM 一次性给答案可靠很多。2.3 端到端把两条链路接起来端到端的难点不只是把“拓扑生成”和“尺寸寻优”各自做好而是让它们共享同一个规格文件、同一种网表格式、同一套仿真反馈协议。如果把两个阶段拆成独立脚本中间很可能出现拓扑变了但测试平台没跟着变、指标格式不统一、网表命名规则冲突等问题。这也是 AaLLM 这类框架最大的工程价值。它需要用一套统一的文本协议串起整个流程规格描述进入模型模型输出拓扑和初始网表脚本做语法检查并调用仿真器仿真器返回工作点、增益、带宽、相位裕度等数据数据再拼成文本反馈给模型模型继续决定下一步。值得多说一句的是这种“LLM 生成候选确定性工具验证结果”的架构和近期在文本挖掘领域出现的 TnT-LLM 等规模化方法在思路上是相通的。区别只是 AaLLM 把“验证工具”从分类器换成了电路仿真器把“目标空间”从文本标签换成了拓扑与参数空间。3. 适用场景与使用边界先看适合什么人。AaLLM 理想的应用场景是模拟电路设计的早期阶段规格指标已经明确工程师想知道有哪些拓扑可选、每种拓扑大概能做到什么性能、初始尺寸应该从哪里起步。这时候让 LLM 先生成一批候选再用仿真器过滤能明显压缩头脑风暴和初版方案的时间。对刚接触模拟 IC 的工程师和学生来说它也可以充当“可以对话的参考设计手册”把教科书里的经典拓扑快速转成可仿真的网表模板。再看它解决什么问题。最直接解决的问题是“从一张指标表到一份可仿真网表”的效率问题。它把设计经验、结构知识和仿真迭代的流程固化下来减少重复劳动。其次是设计空间覆盖问题传统人工设计只会围绕几个已知拓扑打转LLM 可以生成更多结构上有差异的候选配合批量仿真做广撒网。但边界也很明显。不要指望 AaLLM 直接产出可用 tape-out 的电路。真实芯片设计还需要考虑工艺角PVT、失配、可靠性、版图寄生、ESD 和封装效应这些不在拓扑生成和 sizing 的核心范围内。另外LLM 生成的网表会有“语法合法但电学无意义”的问题管子接法没有环路增益、偏置点不在饱和区、补偿电容大得离谱。框架必须靠仿真器把这类结果过滤掉不能信任模型输出本身。这里还要提醒合规和安全边界。如果项目中涉及具体工艺库和 PDK 信息不要随意把器件模型参数、工艺文件内容上传到公共云端大模型 API。建议优先使用本地部署的开源模型或者在获得授权后使用企业内部模型服务。每一份生成的电路都必须自行做仿真与设计规则复核涉及商业项目的拓扑、尺寸和测试平台需要确认知识产权边界避免把他人专有设计直接拼进自研流程。4. LLM 底座本地部署环境准备AaLLM 的下游是仿真器上游是大语言模型。所以环境准备分两条线一条是模型推理环境一条是电路仿真环境。模型推理环境的门槛取决于你选的模型规格。如果你只是想跑通链路可以使用中等尺寸的开源模型量化后部署在消费级显卡上。以常见的部署常识来估算7B 级别模型用 4 bit 量化后显存需求大概在 6GB 上下13B 级别量化后需要 10GB 左右如果换成 70B 级别模型基本要两张以上大显存显卡或者直接走云 API。实际占用还跟上下文长度、并发数和是否使用 vLLM 等推理框架有关需要以本机实测为准。如果你不想折腾显卡直接调用云 API 也能完成拓扑生成实验。这种方式的优点是显存零门槛缺点是如果把 PDK 工艺细节写进提示词会有数据合规风险。下面给出一套本地 Python 环境准备命令按你自己的仓库结构和依赖文件调整即可。# 建一个隔离的 Python 环境 python3 -m venv aallm-venv source aallm-venv/bin/activate # Windows PowerShell 下使用 .\aallm-venv\Scripts\Activate.ps1 # 升级 pip 并安装基础推理依赖 pip install --upgrade pip pip install torch transformers accelerate # 如果要把模型封装成服务安装 API 客户端 pip install openai # 电路仿真器按需安装开源方案可用 ngspice sudo apt install ngspice再检查 GPU 驱动和 CUDA 环境。用下面的命令确认 PyTorch 能看到 GPU这个步骤必须做否则后面模型加载会跑到 CPU 上速度慢到没法做多轮尺寸迭代。python -c import torch; print(torch.cuda.is_available(), torch.cuda.device_count(), torch.cuda.get_device_name(0))输出True 1 NVIDIA ...说明 GPU 可用。如果输出 False先检查驱动版本再重装对应 CUDA 版本的 PyTorch。仿真器和模型推理环境建议分别做验证先用一个 hello world 的 SPICE 文件测试 ngspice 是否可用再用一句固定 prompt 测试模型能不能正常输出两者都通了再进入 AaLLM 流程。5. 端到端流程拆解与最小实验配置5.1 规格输入的标准化要让 LLM 稳定生成拓扑首先要有一个固定格式的设计规格。两种输入方式比较常见一是自然语言描述比如“设计一个 1.8V 电源、负载 2pF、直流增益不低于 80dB 的两级 Miller 运算放大器”二是结构化配置例如 YAML 或 JSON。实际项目中两种方式经常结合结构化配置用于程序解析自然语言描述用于喂给模型。下面是一个可复用的规格配置模板task: circuit_type: two_stage_miller_ota spec: supply: 1.8 load_cap: 2e-12 dc_gain_db: 80 gbw_mhz: 50 phase_margin_deg: 60 power_mw_max: 1.0 topology_candidates: 8 sizing_iterations: 5 simulator: engine: ngspice netlist_dir: ./netlists testbench_dir: ./testbenches output_dir: ./results这里topology_candidates表示要让模型生成几个候选拓扑sizing_iterations表示每个拓扑最多做几轮尺寸迭代。第一次跑实验不建议把这两个数字设太大先用 3 到 5 个候选、3 轮迭代把链路跑通再逐步扩大规模。5.2 拓扑生成阶段的提示词设计提示词质量直接决定生成网表的可用率。一个有效的做法是在系统提示词里限定输出格式要求模型只返回 SPICE 网表和必要注释不要输出大段解释。下面是一个参考用的系统提示词模板你是一名资深模拟集成电路设计工程师。请根据用户给定的设计规格生成对应的模拟电路拓扑和 SPICE 网表。 要求 1. 网表必须语法完整器件名、节点名、模型名需要区分清楚 2. 每个 MOS 管需要给出初始 W/L 和 m 值 3. 输出格式为纯 SPICE 代码块不要输出额外解释 4. 如果用户要求多个候选请给出结构差异明显的方案。在具体请求中再拼接规格内容。这里有一个容易踩的坑如果不限定输出格式模型经常会输出“下面是网表”这类解释文本解析脚本很容易报错。更稳妥的方式是让解析脚本只提取代码块内容并对剩余文本做兼容处理。5.3 网表解析与语法校验LLM 输出的网表不能直接信任。第一步是检查语法器件名是否规范、节点是否悬空、模型名是否存在、MOS 管描述是否完整。建议把这一步做成独立模块解析失败就直接丢弃该候选不要进入仿真。下面是示意代码具体解析逻辑取决于你的网表格式约定。import re def extract_spice_blocks(text: str) - list[str]: return re.findall(rspice\n(.*?), text, flagsre.S) def basic_netlist_check(netlist: str) - bool: required [.subckt, M1, VDD, VSS] return all(keyword.lower() in netlist.lower() for keyword in required)这里要注意语法校验能过滤掉低级错误但过滤不了“看起来合法却工作不了”的电路。判断网表是否真的满足指标必须靠仿真器。5.4 Sizing 迭代循环的最小实现把拓扑生成和尺寸迭代串起来后最小流程可以写成下面这样。这个流程不依赖 AaLLM 的具体源码适合用来验证“LLM 生成电路 仿真器反馈”的思路是否在你的模型和仿真器组合下有效。def run_one_spec(spec: dict, max_iter: int 5): netlist llm_generate_topology(spec) if not basic_netlist_check(netlist): return None for iteration in range(max_iter): result simulator.run_testbench(netlist, spec) if result.meets_spec(): return result hint build_feedback_text(spec, result) netlist llm_sizing_fix(spec, netlist, hint) return resultbuild_feedback_text是关键。建议把仿真结果整理成可读的文本再丢给模型例如“当前直流增益 55dB目标 80dBGBW 30MHz目标 50MHz相位裕度 45 度目标 60 度。输出级偏置电流偏小请调整相关管子尺寸。”不要只给一长串原始仿真日志模型在长文本里提取关键指标的准确率会下降很多。6. 功能测试与效果验证6.1 拓扑生成能力测试测试目标是回答三个问题模型能不能生成语法完整的网表生成的结构是不是真的有差异差异是不是有意义的拓扑差异。测试方式是每次让模型生成 5 个运算放大器拓扑规格保持相同温度参数可以设为 0.7 左右增加随机性。然后把所有结果送入语法解析器统计“语法通过率”。再看通过语法检查的网表结构判断其中是否存在真实的拓扑差异例如一个用 cascode 负载另一个用电流镜负载而不是只换了宽长比数字。判断成功的标准是语法通过率大于一半且有效拓扑数量不少于 3 个。如果模型反复生成几乎相同的结构说明提示词里缺少“给出结构差异明显的方案”之类的约束如果语法通过率持续偏低则需要先检查系统提示词中的格式限制。6.2 初始尺寸生成测试这一节验证的是 LLM 给出的初始 W/L 和偏置是否落在可工作区间。测试目标是让模型生成两级 Miller OTA 并给定初始偏置然后送入 ngspice 跑 DC 工作点看所有 MOS 管是否工作在预期区域比如饱和区。如果大量器件工作在截止区或线性区不要急着给模型加压。先检查提示词是否明确给出了电源电压、负载电容、尾电流源目标等约束。初始尺寸阶段允许有偏差因为后续的 sizing 循环本来就是要修正这些偏差但偏置点错得离谱是明显信号说明模型没有理解器件工作区约束。6.3 Sizing 收敛性测试sizing 是 AaLLM 最核心的验证模块。测试方式是把第 5.4 节的迭代循环跑起来设一个统一的规格表作为目标。参考指标如下指标目标值判定标准DC 增益大于等于 80 dBAC 仿真低频增益达标GBW大于等于 50 MHzAC 仿真 0dB 交叉频率达标相位裕度大于等于 60 度GBW 处相位检查达标功耗小于等于 1 mWDC 工作点功耗未超标负载电容2 pF测试平台按此设定记录每个候选拓扑在第 1 轮、第 3 轮、第 5 轮的指标变化观察是否朝目标方向收敛。判断成功不只是看最终是否达标还要看指标变化趋势是否合理。如果第 3 轮比第 1 轮更差说明模型没有正确理解反馈文本或者反馈信息量太大导致上下文丢失如果完全不变化说明反馈没有真正进入下一轮生成。6.4 失败原因归类当一轮实验失败后要先定位失败发生在哪一层语法层失败模型产生的不是合法 SPICE解析器直接过滤。排查提示词和输出格式限制。仿真层失败网表合法但仿真不收敛。排查模型文件是否完整、是否存在浮空节点、器件极性是否接反。指标层失败仿真跑通但结果偏离规格。排查 specs 输入格式、反馈文本是否完整、模型是否能区分拓扑级问题和参数级问题。系统层失败流程中断或脚本报错。排查目录路径、测试平台文件是否随拓扑自动更新。把这四类失败分开记录比笼统地看“成功率”更有用。如果指标层失败集中在某个特定拓扑说明 LLM 对该拓扑的建模理解不深下一轮实验应该降低该拓扑的生成权重。7. 接口 API 与批量任务接入7.1 把模型推理封装成服务当验证流程跑通后拓扑生成、sizing 迭代、仿真调度这些任务就不应该一个进程内循环执行建议把模型推理封装成标准服务业务端通过 API 调用。使用 vLLM、llama.cpp server 或同类推理框架可以快速得到一个 OpenAI 兼容的服务端口。下面是通用调用示例。注意这里的地址、模型名必须按你实际启动的服务调整。curl -s http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: your-local-model, messages: [ {role: system, content: 你只输出合法 SPICE 网表。}, {role: user, content: 生成两级 Miller OTA 的 SPICE 网表电源 1.8V负载 2pF。} ], temperature: 0.2 }返回内容一般是 JSON从choices[0].message.content字段取生成文本即可。7.2 Python 客户端与批量任务封装单规格实验只能验证功能真正有价值的是批量探索。模拟设计经常需要对比不同负载电容、电源电压、增益指标下的拓扑和尺寸方案。这种情况下可以把规格列表存成文件逐条提交到模型服务。import requests API_URL http://127.0.0.1:8000/v1/chat/completions def ask_topology(spec_text: str, temperature: float 0.2) - str: payload { model: your-local-model, messages: [ {role: system, content: 你是模拟 IC 设计助手只输出 SPICE 网表。}, {role: user, content: spec_text} ], temperature: temperature, max_tokens: 2048, } resp requests.post(API_URL, jsonpayload, timeout120) resp.raise_for_status() return resp.json()[choices][0][message][content] specs [ 设计两级 Miller OTA电源 1.8V负载 1pF增益大于 70dBGBW 大于 30MHz, 设计两级 Miller OTA电源 1.8V负载 5pF增益大于 80dBGBW 大于 20MHz, ] for idx, spec in enumerate(specs): text ask_topology(spec) with open(f./outputs/topology_{idx}.spice, w, encodingutf-8) as f: f.write(text)批量任务要注意两个问题。一是并发控制不要一次性打爆模型服务建议按推理框架的实际能力设置并发数。二是失败重试API 请求可能会因为超时、服务端偶发错误而失败批量调度器需要记录失败任务并支持重跑而不是直接中断整个队列。最简单的方式是在每条任务输出文件中同时写一个状态文件标记pending、running、done、failed四种状态。8. 资源占用与性能观察8.1 模型推理资源占用LLM 推理的显存占用主要看模型参数量、量化精度、上下文长度和 batch 大小。要观察真实占用用 nvidia-smi 实时看是最直接的。启动模型服务后在一个新终端执行watch -n 2 nvidia-smi重点看推理进程的显存占用和 GPU 利用率。如果 GPU 利用率长期低于 10%说明模型参数不大瓶颈可能在 CPU 端的分词或调度如果显存占用在推理过程中持续增长可能是上下文太长或 vLLM 缓存设置过大。显存不足时优先考虑四项调整降低并发、缩短输入历史长度、换更低 bit 的量化、换更小的模型。8.2 电路仿真的资源占用电路仿真通常是 CPU 密集任务尤其跑 AC、瞬态和 PVT 扫描时。和 LLM 推理不同ngspice 这类开源工具基本不吃 GPU但会占满 CPU 核心。批量跑几十个候选拓扑时不要一次性把所有仿真都丢进去建议只并行和 CPU 核数接近的任务数避免互相拖慢。8.3 延迟分布观察整个 AaLLM 流程的延迟由三部分组成模型生成延迟、仿真执行延迟、反馈整理延迟。第一次跑实验时建议把每一段单独计时搞清楚瓶颈在哪里。有时候你会惊讶地发现一次 SPICE 瞬态仿真的耗时比一次 LLM 调用还长那重点优化方向就应该是测试平台的激励设置和仿真精度而不是换更大的模型。如果模型生成延迟占比过高优先检查是不是每次迭代都把完整的网表历史重新发送了一遍。合理的做法是只发送当前 netlist 和最新的仿真反馈把已完成的拓扑搜索结果存在本地文件里不要全部塞进上下文。9. 常见问题与排查方法下表覆盖了这类 LLM仿真器流程中最常见的问题。遇到异常时按“现象、原因、排查、方案”的顺序走不要先怀疑框架本身。问题现象可能原因排查方式解决方案模型输出不是合法 SPICE提示词没有约束输出格式查看原始输出确认是否包含大段解释在系统提示词中强制“只输出 SPICE 代码块”并增加解析过滤网表语法通过但仿真不收敛器件节点接错或模型文件缺失检查 ngspice 报错日志定位具体器件对照参考网表检查节点连接补充模型库声明仿真跑通但指标完全不变LLM 没有接收到反馈文本打印每次送入模型的完整消息检查反馈构造逻辑指标偏差必须显式写入下一轮 prompt显存不足或推理卡死模型太大或并发过高用 nvidia-smi 观察显存变化降低并发、缩短上下文、换低 bit 量化模型批量任务跑到一半停止单次 API 请求超时未处理查看任务状态文件增加超时重试和失败任务状态标记LLM 生成的初始尺寸偏置点错误缺少器件工作区约束调用 DC 工作点仿真查看 Vgs、Vds在提示词中加入“所有管子应工作在饱和区”等约束反馈文本过长导致模型注意力分散原始仿真日志太大观察输入 token 数只抽取关键指标用固定格式拼接反馈这里要特别提醒当某一轮实验表现很差不要急着换模型或调温度。先检查数据链路是不是出了问题。在 AaLLM 这种多模块流程里相当一部分失败来自规格字段解析错误、输出目录不存在、测试平台与拓扑不匹配等低级问题而不是模型能力不足。10. 最佳实践与使用建议10.1 先固定一套最小可运行配置在尝试复杂实验前先固定一个最小可运行配置一个规格、一种拓扑、一轮仿真。确认从 LLM 到仿真器再到反馈文本的链路完全打通后再扩展候选数量和迭代轮数。最小配置最好存成独立目录作为后续对照试验的基准。10.2 用结构化输出避免模型自由发挥LLM 生成内容天然不稳定越自由越难解析。建议在提示词中强制使用代码块、JSON、固定字段等结构化输出再用脚本做严格解析。拓扑生成阶段可以允许多样性但尺寸修改阶段应尽可能要求模型在给定网表上做局部修改而不是每次重新生成一份新网表。10.3 建立“候选-仿真-结果”三级目录目录管理做不好批量实验会很混乱。推荐结构是每个规格一个父目录下面按拓扑候选编号建子目录每个子目录里放输入网表、测试平台、仿真日志和结果摘要。所有原始输出统一存文件不依赖数据库也能回溯。10.4 不要把仿真相绝于 LLM 上下文之外LLM 是无状态的框架必须负责把仿真结果组织成有意义的反馈。每次迭代建议只给“当前偏差 期望目标 建议关注方向”三块信息。如果发现模型多次修改仍不收敛可以尝试让模型先给一段诊断文字说明它认为瓶颈在哪再给修改后的网表这种“先推理再输出”的方式能明显提高复杂问题的修复率。10.5 合规与复核生成电路和自动 sizing 都只能作为设计辅助不能替代正式设计评审。涉及具体 PDK 文件、工艺参数、尺寸数据时务必确认信息使用边界任何准备进入流片或商用的设计都要由有经验的工程师做完整复核。把 AaLLM 定位为“快速生成候选方案和初版尺寸的助手”而不是“无人值守的流片工具”使用姿态会安全得多。11. 总结与下一步AaLLM 这类项目值得关注的点不是“LLM 能写网表”这个表面能力而是它把模拟电路设计中两个最依赖人工的环节用一套端到端框架串了起来。拓扑生成负责探索结构空间sizing 负责在仿真反馈下逼近设计指标两者共用一套规格和反馈协议。这个思路本身比单个功能点更有参考价值。如果你打算自己试最先要验证的不是跑通 AaLLM 的完整管线而是先确认你选的 LLM 能不能稳定生成语法正确的经典运算放大器网表。第一步可以从一个两级 Miller OTA 开始让模型生成 5 个候选拓扑用 ngspice 跑 DC 和 AC 仿真统计有效率和达标率。这个实验成本不高却能快速判断模型和仿真器组合是否值得继续投入。最容易踩的坑是忽略网表解析和仿真反馈设计提示词写得再好没有可靠的解析器和反馈循环LLM 也只能输出一堆不能自动收敛的文本。后续值得扩展的方向包括把 LLM 生成的候选结果接入贝叶斯优化或遗传算法做二次筛选给不同拓扑打标签并建立历史结果库让后续任务少走弯路把仿真反馈从文本改为结构化数据配合本地模型精细调优进一步提升尺寸收敛率。建议先把这篇文章里的最小链路跑通再决定往哪个方向深入。