PyAether：用Python脚本化芯片设计，从原理图到版图的自动化实践

1. 从画板子到写脚本EDA自动化到底在解决什么问题1.1 我为什么从GUI操作用户转成写脚本画电路做了几年的芯片设计我发现自己每天花在版图和原理图上的时间真正设计的部分其实占不到一半。大量时间消耗在重复性劳动上摆放一批尺寸相同的MOS管、给一百根信号线统一改命名规则、把某个单元在阵列中复制成8×8、每次生成完版图后都要重新设置一遍检查规则再导出报告。这种东西在GUI里点来点去一天下来眼睛酸、手累而且特别容易出错——漏改一个参数、连错一根线有时候要等仿真跑完才发现。后来我接触了PyAether才算真正理解什么叫用Python做芯片设计。它跟我过去理解的EDA完全不同——不是在GUI上偶尔提供一个脚本入口而是把整个设计流程都暴露成Python对象。你可以像写普通软件一样用循环、判断、函数、类来组织你的设计流程。创建工程、建库、建cell、放器件、连线、跑检查、生成版图全部可以通过脚本完成。也就是说你在芯片设计里做的所有常规动作理论上都能用Python重新实现一遍。这篇文章适合三类人一类是在校学生正被EDA课程的作业折磨与其手工画一晚上版图不如花一小时写个脚本一类是传统IC设计工程师看了太多Skill/Tcl脚本但觉得学习成本高想看看Python化之后到底是什么体验还有一类是做软件出身、想切入芯片设计领域的人PyAether这种工具可以让你用熟悉的语言快速上手EDA的核心流程。1.2 传统EDA脚本生态的痛点在哪在PyAether出现之前EDA领域的自动化其实走的是另一条路。Cadence环境里最经典的是Skill语言专门用于定制其工具行为Mentor/Siemens那边则常用Tcl的callback机制来串联流程。这些方案解决了很多工业化问题但有一个共同的毛病学习成本高且语法陈旧。我记得有人统计过一个做模拟版图的工程师至少要花两三个月才能真正用好Skill。而且这语言只在特定工具链里有用离开这套环境就毫无价值。年轻一代工程师学校里学的是Python、C、Verilog你让他再去啃一门只有少数公司内部才用的脚本语言心理门槛非常高。再加上Skill的调试体验比较弱没有像Python那样丰富的错误提示和交互式调试环境写起来很不顺手。开源工具那边也有脚本化生态但绝大多数走的是Tcl/TK路线偏底层、偏命令化。你要写一个把当前选中的所有器件顺时针旋转90度这种操作都得先学会一套复杂的命令语法。PyAether给我的感觉完全不同它的核心设计思路是The Design is the Code设计本身就被表达为Python代码而不是在第三方工具上套一个脚本外壳。1.3 PyAether在芯片设计流程中的定位其实PyAether并不是要替代整个EDA流程它更像是一个用Python语言重新打造的设计前端。把布局布线引擎、设计规则检查这些重活都封装在底层对外提供一套Python接口。你不需要掌握底层引擎的复杂度只需要知道调用哪些对象和方法。举个简单例子你不需要理解一个版图编辑器是如何处理图形渲染的你只需要用layout.add_rect()这样的方法画一个矩形。这就把EDA里最复杂的东西和设计师真正关心的东西解耦了。我在实际使用中的体验是当设计对象变为代码后很多以前不敢想象的流程变得稀松平常——比如把一组参数传给某个函数让它生成几十种不同尺寸的测试结构这在传统GUI流程里是难以实现的。从流程角度来说PyAether适合做从原理图到版图的完整定制化flow尤其适合做各种参数化单元生成、批量版图衍生、设计自动化验证辅助。接下来我就从零开始讲讲怎么把环境跑起来然后一步步用脚本完成一个实际设计任务。2. PyAether的安装与首个Python脚本2.1 环境准备最容易踩坑的两个地方先说Python环境。PyAether本质上是Python库所以首先需要保证你有一个能正常工作的Python环境。以我接触的发行版本为例通常建议Python 3.8及以上。不一定非要最新版但3.8以下版本大概率会有兼容性问题。我一般用python3 -V先确认一下当前版本不够就装个新的。再来是建议使用虚拟环境。很多初学者图省事直接在系统环境里pip install结果过两天发现依赖冲突要么就是之前装的其他工具被升了级。我个人强烈建议凡是牵涉到EDA库的Python环境一律用venv或者conda单独建一个环境。这样即使把环境搞坏了也不会影响日常开发环境。mkdir pyaether_demo cd pyaether_demo python3 -m venv venv source venv/bin/activate pip install pyaether注意如果公司内网环境比较严格可能需要配置pip源或者直接从项目官网下载wheel包离线安装。安装完之后验证一下是否导入成功python -c import pyaether; print(pyaether.__version__)只要这行命令不报错环境就算是通了。2.2 第一个脚本创建工程并建立原理图页我一直认为学任何EDA工具第一步都应该做同一件事创建一个最小的工程然后在里面建立一个cell把文件生成出来在GUI里打开看一眼。这样你能立刻明白工具的工作方式同时确认自己的环境配置正确。下面这个脚本就是一个最小示例逻辑很简单初始化项目结构、创建库、创建一个schematic类型的cellimport pyaether as pya # 初始化项目项目名与路径你能自定义 proj pya.open_project(demo_project, path/to/demo_project) # 创建一个库库名可以理解为器件集合 lib proj.create_library(my_lib) # 创建一个celltype指定为schematic原理图 cell lib.create_cell(inv_chain, typeschematic) # 保存工程 proj.save() print(project created:, proj.path)跑完之后你可以去对应目录看看生成了哪些文件再用PyAether自带的GUI工具打开这个工程应该能看到一个空白的原理图页面。成功看到这个页面说明你的整个链路没问题Python环境→PyAether库→图形界面→工程文件。我第一次跑通这个脚本的时候最大的感受是原来EDA工程文件本质上就是一组可复现的代码生成结果。这跟直接用GUI建工程完全不同GUI是操作即结果而脚本是代码即结果。你做过的每一步操作都白纸黑字写在代码里出了问题可以回查可以版本管理可以团队共享。2.3 跑通脚本后我建议立刻验证的三件事跑通最小示例只能说明环境没问题但离真正能干活还有一段距离。我建议你接下来做三个验证动作第一改装一下刚才的脚本把create_cell的type从schematic改成layout再运行一次。确认你能生成版图类型的cell。因为很多设计流程最终要落到版图如果这个通道没打通后面会卡住。第二在脚本里试着创建一个library之后再删除它再创建一个反复几次。确认没有残留文件和意外报错。这个小实验看起来无聊但能帮你理解库和文件的映射关系。我在用某些EDA库时遇到过删了库但磁盘上文件还在的情况导致后来重名创建失败。第三把工程保存后尝试在不调用GUI的情况下用脚本直接打开这个工程并读取里面的cell列表proj pya.open_project(demo_project, path/to/demo_project) lib proj.get_library(my_lib) cells lib.list_cells() print(cells)这一步验证的是无头模式headless mode能不能正常工作。如果你能跑通后面就能在服务器上批量跑设计脚本了这在传统GUI流程里几乎不可能做到。很多做自动化flow的工程师最看重的就是这一点——能不能没有显示器的环境下在集群上批量处理设计数据。3. 核心API拆解用Python对象操纵原理图与版图3.1 工程、库、单元三层结构的Python表达PyAether的对象模型理解起来其实跟文件系统很像。最顶层是工程Project相当于一个总目录可以包含多个库中间层是库Library相当于分类目录通常按工艺、单元类别或项目模块来区分最底层是单元Cell对应一个具体的原理图或版图。我习惯用文件夹-子文件夹-文件来类比这三层关系因为实际操作时工程目录下的磁盘结构也确实是这么组织的。理解了这一层你就明白为什么所有操作都要先open_project——不打开工程工具就不知道你操作的是哪棵目录树。其中值得留意的是create_cell里的type参数。同一个cell名称下可以有不同的视图类型schematic原理图、layout版图、symbol符号。这跟传统EDA工具里的view概念一致。实际设计中设计一个反相器这个任务在工程里会体现为一个cell名下同时存在schematic视图和layout视图。你在脚本里要操作哪个视图就打开对应类型的cell对象。3.2 从原理图到版图的自动化通路传统EDA流程里原理图到版图往往需要手工映射你画完原理图得手动打开版图编辑器重新画一遍或者借助自动布局布线工具做转换。PyAether的一大特色是提供了一条比较顺畅的原理图到版图的脚本化通路。我这边常用的做法是先在原理图里把电路结构和参数定义好然后用脚本读取原理图里的器件实例和连接关系再在版图视图里根据这些信息调用对应的生成函数。整个数据流可以理解为原理图cell → 提取器件与net → 逐项实例化到版图 → 自动布局 → 布线实际写代码时你可以在同一个脚本中同时持有原理图和版图两个cell的句柄sch lib.create_cell(amp, typeschematic) lay lib.create_cell(amp, typelayout) # 在原理图中添加一个NMOS实例 nmos sch.add_device(NMOS, M1) nmos.set_param(w, 5u) nmos.set_param(l, 0.5u) # 在版图中生成对应的NMOS图形集合 nmos_lay lay.add_instance(nmos, M1) nmos_lay.set_origin((100, 100))这里我只是做了一个很粗略的示意真实的API可能叫add_device或create_instance不同版本略有差异。但核心逻辑是统一的原理图里的器件和版图里的物理图形在PyAether里是同一个对象在不同视图下的投影天然关联而不是两个独立的手工实体。3.3 批处理场景批量生成、矩阵摆放与自动连线如果说单器件操作只是入门那批处理才是脚本自动化的核心价值所在。我做过一个项目需要生成一个8×8的晶体管阵列每个晶体管的W/L略有差异传统手动方式要创建64个器件、手动设置参数、摆放、连线至少要小半天。用脚本做其实就是两段循环的事。# 假设 lib 和 lay 已经创建好 rows range(8) cols range(8) for i in rows: for j in cols: dev lib.create_device(NMOS, fNMOS_{i}_{j}) inst lay.add_instance(dev, fi_NMOS_{i}_{j}) inst.set_param(w, f{2 i * 0.5}u) inst.set_param(l, f{0.18 j * 0.02}u) inst.set_origin((i * 50, j * 30))这段代码的核心价值不在代码本身而在于它把重复劳动变成了可参数化、可复用的逻辑。如果明天需求变成12×12阵列你只需要把range(8)改成range(12)所有参数自动重新生成。这在GUI里是不可想象的——你不可能为了改个尺寸把64个器件全部重新摆一遍。自动连线在脚本里也完全可行。PyAether提供了一系列几何计算和路由接口可以根据器件端口坐标自动生成金属连线。更先进一点你还可以把连线规则写成函数——比如所有电源线用M3层横向走线所有地线用M4层纵向走线间距不小于0.3um——这种规则化思维几乎就是现代版图设计的正确姿势。4. 一个完整实战用脚本自动搭建差分对并生成版图4.1 需求拆解光讲API概念没用我们直接拿一个实际例子来走一遍。假设我现在需要设计一个最基本的差分输入对两个尺寸完全相同的NMOS管源极相连并引出尾电流端口两个栅极分别作为正负输入两个漏极分别作为正负输出。传统做法是打开原理图编辑器拖两个晶体管设置参数画三根线再打三个端口pin。看起来不难但是如果你要在不同工艺角、不同尺寸条件下重复做10组那就要重复10次。而脚本方式只需定义一次流程再批量跑。我先把这个需求拆成几个动作创建工艺库和cell在原理图视图添加两个NMOS管设置相同尺寸绘制源极到公共节点的net引出尾电流端口分别引出输入端口和输出端口在版图视图做同样的器件实例化并摆放运行设计规则检查的脚本接口4.2 完整代码与逐段解读下面给出代码主体逻辑。首先建工程和cellimport pyaether as pya proj pya.open_project(diff_amp_proj, path/to/diff_amp_proj) lib proj.create_library(design_lib) sch lib.create_cell(diff_pair, typeschematic) lay lib.create_cell(diff_pair, typelayout)然后添加两个NMOS管并设置参数。这里我把所有几何和参数都定义为变量方便复用和后续批量扩展W 4u L 0.5u m1 sch.add_device(NMOS, M1) m1.set_param(w, W) m1.set_param(l, L) m2 sch.add_device(NMOS, M2) m2.set_param(w, W) m2.set_param(l, L)接着连线和添加端口。这里面的逻辑是每根net在原理图里都是一个对象把器件端口归属到这个net对象上tail_net sch.create_net(tail) tail_net.connect(m1.get_pin(S)) tail_net.connect(m2.get_pin(S)) sch.create_pin(TAIL, tail_net) inp_net sch.create_net(INP) inp_net.connect(m1.get_pin(G)) sch.create_pin(INP, inp_net) inn_net sch.create_net(INN) inn_net.connect(m2.get_pin(G)) sch.create_pin(INN, inn_net) outp_net sch.create_net(OUTP) outp_net.connect(m1.get_pin(D)) sch.create_pin(OUTP, outp_net) outn_net sch.create_net(OUTN) outn_net.connect(m2.get_pin(D)) sch.create_pin(OUTN, outn_net)版图部分最关键的是保证两个管子的对称性。在脚本里这意味着它们的坐标关系必须严格对称。比如我把M1放在原点那么M2就放在相对于对称轴镜像的位置lay_inst1 lay.add_device_instance(m1, M1) lay_inst1.set_origin((0, 0)) lay_inst2 lay.add_device_instance(m2, M2) lay_inst2.set_origin((20, 0)) lay_inst2.set_mirror(MX) # 关于X轴镜像保证源极可以合到一起最后运行设计规则检查的脚本接口确认版图没有违反基本规则result lay.run_drc() print(DRC violations:, len(result.violations))就这样一个差分对的原理图加版图在脚本层面就完成了。整个过程大概几十行代码但逻辑非常清晰别人看了代码就能理解你的设计意图这是GUI操作完全给不了的。4.3 运行结果与人工对比我实际跑完这个脚本后又特意用传统GUI方式重新做了一遍同样的设计做了一个时间对比。手工画原理图版图熟悉流程的工程师大概需要10到15分钟而写脚本第一次跑通大约花了40分钟因为要调试API但第二次起只需要改几个参数然后执行不到1秒钟就能输出结果。这个差距在批量生成测试结构时会被拉得更大。正确率方面脚本也明显占优。手工操作时连线连错、器件参数漏改都是常见问题尤其当结构复杂时返工成本极高。脚本方式中只要你定义好了规则每一次生成的正确性都是一样的不会因为下午三点犯困而引入失误。我在那次对比后彻底改变了自己做版图验证的方式。凡是重复超过三次的操作我都会停下来想想能不能写脚本。这已经不是为了炫技而是为了效率。5. 车规、NPU这类新流程里脚本自动化为什么是刚需5.1 车规级EDA flow对可追溯性的要求如果你接触过车规级芯片的设计流程一定知道可追溯性这三个字有多重。车规芯片要过功能安全认证每条设计决策都要能回答为什么这么做、什么时候做的、谁做的这个问题。传统GUI操作模式下这种追溯是极其困难的你只记得我当时在界面上点了几个按钮但到底点了什么、参数是什么很难精确还原。脚本化的流程天然就是可追溯的。每一份设计结果都对应一份代码代码跑出来的log就是这个设计的完整历史。我之前配合过功能安全审计对方要求提供某一个版图单元的生成依据我直接把当时的Python脚本和输出的log文件打包交上去整个沟通过程非常顺畅。人工解释半天的内容脚本白纸黑字一清二楚。车规流程里还有大量重复的可靠性验证工作比如不同温度下的版图检查、不同金属层组合的电流密度验证。这些本质上就是同一套逻辑在不同参数下的运行。用手工做一次还可以忍做十次、二十次出错率必然上升。而脚本参数化之后只需要写一个循环遍历参数组合自动生成所有结果并汇总成报告。5.2 NPU设计中的重复单元与参数化NPU神经网络处理器是近几年芯片设计里最热的方向之一。它的版图结构跟传统数字芯片有一个显著区别大量重复的运算单元阵列。一个NPU里可能包含几十甚至上百个完全相同的PEProcessing Element单元每个PE内部又包含了乘法器、累加器、SRAM、控制逻辑。这种结构简直是脚本自动化的天选场景。用传统方式做PE阵列的版图你得先做一个单元验证无误然后手动实例化成阵列。听起来有标准流程但问题在于——你怎么保证100个实例是完全一致的你手动放置时稍微偏了一点坐标怎么办阵列之间的布线如何保证完全等长脚本方式直接绕开了这些问题。你只需要定义一个生成单个PE的函数然后在一个双重循环里实例化N×N次。坐标计算交给代码镜像、旋转也交给代码。我之前帮朋友做过一个8×8 PE阵列的布局脚本核心逻辑不超过200行但生成的版图结构规整、完全对称这在手工时代是不可想象的。NPU设计还有一个特点是迭代频繁——算法团队可能每周都改一次PE内部结构。如果版图画死了改一次就要重新人工调整。但如果你把PE单元封装成Python函数内部结构变了只要函数逻辑更新所有阵列实例自动跟着变。这就是参数化设计的巨大优势。5.3 从PyAether看EDA工具的未来我个人的判断是PyAether这类的工具代表了EDA工具演进的一个清晰方向从图形界面为主脚本为辅转向脚本为主图形界面为辅。为什么这么说因为芯片设计的复杂度在持续上升而人脑能同时处理的细节数量是有上限的。当设计规模达到一定程度靠鼠标点击来管理设计细节已经变得不现实。你必须把设计意图从操作提升到逻辑层面——我关注的是结构、规则、策略而不是这里点一下、那里拖一下。我记得以前用一个老牌EDA工具时它的脚本语言能做的事情非常有限大多数操作还是需要回到GUI里完成。PyAether给我的感觉完全不同你在GUI里能做的几乎所有事情都能在Python里找到对应的接口甚至很多底层操作是GUI根本没有暴露出来的。这意味着你能做的事情比界面上看到的更多而不是更少。对这个行业的人来说尽早掌握脚本化的设计方式等于给自己的职业生涯加了一个巨大的杠杆。它不会取代你作为设计师的判断力但能把你从繁琐的重复劳动中解放出来让你把精力放在真正需要人脑才能完成的事情上。6. 我踩过的坑和一些操作习惯分享6.1 脚本写多了之后我的三个习惯使用PyAether一段时间后我形成了一套自己的操作习惯这里分享给你。第一个习惯是每个项目都建独立的虚拟环境并把依赖版本锁定在一个requirements.txt里。EDA库的版本更新往往不像web框架那么频繁但这反而意味着不同版本之间的接口差异可能很大。我之前就遇到过项目A用的旧版本API写的脚本在升级新版本后跑了不到一半就报异常。锁定版本并在脚本头部打印版本号可以避免大量类似问题。第二个习惯是把设计参数集中定义在脚本顶部用有意义的变量名表达。比如不要直接写set_origin((100, 100))而是先定义M1_X_OFFSET 100然后写set_origin((M1_X_OFFSET, M1_Y_OFFSET))。这样做的好处是当你的设计参数需要调整时不需要在几百行代码里找散落的数字只需要改顶部几个变量。这种习惯在尺寸参数多的模拟版图设计里尤其有用。第三个习惯是分步保存设计进度。每完成一个逻辑阶段——比如建好cell、放完器件、连完线——就保存一次并把保存时点的状态打印到日志里。这样如果后续某一步跑挂了你可以清楚地知道挂在哪一步而且可以从最近的保存点继续而不需要从头再来。我把这个习惯叫做设计留痕在自动化流程里非常重要。6.2 排查脚本问题的三个核心思路遇到脚本报错时我总结了三个排查思路基本能覆盖大多数情况。首先是分离法。先判断报错是出在Python层还是EDA工具层。如果报错信息里带pyaether前缀且包含Python的traceback那通常是API用法不对如果报错文件后缀是工具原生格式那大概率是设计规则或几何问题。这个判断能帮你少走很多弯路。其次是打印对象信息。Python的最大优势就是交互式调试你可以随时print一个对象的属性看看它到底是什么、包含哪些内容。我调试PyAether脚本时最常用的命令就是print(dir(some_object)) print(some_object.get_params())这两个命令能告诉我当前对象有哪些可用方法、当前参数是什么比翻文档快多了。最后是最小化复现。当一个复杂脚本报错时我通常会把脚本裁成一个最小版本——去掉所有非关键操作只留下报错相关的代码然后在这个最小版本上逐行调试。很多时候问题会在这个过程里自己暴露出来比如某个对象没有正确初始化或者某两个操作之间存在隐性的先后依赖。这种方式在查上一次运行还好好的这次就不行了这类诡异问题时尤其有效。7. 一点实在的建议从哪个方向开始练手如果你看完文章想要开始尝试我的个人建议是不要一上来就写复杂的完整设计脚本而是从自动化最近一次手工操作开始。比如你上周手工画了一个版图今天就要把它改一版那就试着用脚本完成这次修改。不要追求一步到位而是要感受把操作转成代码的思维方式。第一次可能比手工还慢这很正常。我已经写了不下几十个脚本但遇到全新类型的任务时前期依然会花不少时间摸索API和调试。一个比较推荐的练手路径是先从建库和建cell开始用脚本创建一批空cell然后在原理图视图里用脚本添加器件和连线接着尝试在版图视图里实例化已有单元并摆成阵列最后再试着自己定义可复用的生成函数。这条路走下来你对PyAether的能力边界就有了比较清晰的感知——知道哪些你可以放心交给脚本哪些还是需要回到GUI里人工确认。我在实际使用中最满意的一个项目是用脚本在一天内生成了两百多个不同尺寸的DUT测试结构供产线测试芯片用。换做手工方式这个量级至少需要一周。而且脚本生成的每个结构都有完整的日志和参数记录后续产线反馈有疑问时我可以快速回溯每一个结构的具体生成条件。这种体验让我更加坚信芯片设计行业正在走向设计师写代码代码产生设计的时代。