版图绘制助手 uos1231234/dsh-plugin-virtuoso-layout

dsh-plugin-virtuoso-layout

一个 AI 智能体，驱动 Cadence Virtuoso 画版图——打包成 DeepSeek Harness 插件。

12 个宿主机侧工具，零运行时依赖，在 RHEL 6.5 VMware 虚拟机里驱动 Virtuoso 6.1.7-64b。已在真实 SMIC 0.18 µm 工艺上端到端验证：它产出的版图通过 Calibre DRC，零几何违例；通过 LVS，被识别为 <model> 器件。

它画出的版图

这到底是什么

不是点菜单的脚本。命令是在运行中的 Virtuoso CIW 里求值的 SKILL 表达式：

host (this plugin, Node.js)
│ SSH / SCP
▼
guest (RHEL 6.5)
│ virtoso-bridge daemon on :65452 ◄── SSH tunnel to 127.0.0.1:65453
▼
ramic_bridge.il inside the CIW
│ evalstring("(progn …)")
▼
Cadence database API → dbCreateRect / dbSave / cv~>shapes

因为走的是数据库 API 而不是 GUI，智能体能陈述版图的事实——「18 个矩形，bbox ((0.2 −1.0) (2.2 1.68))，栅长 0.18 µm」——而不是对一张图发表看法。

XTEST 键鼠注入确实存在，但只用来解开卡住的模态对话框。它从来不是主通道。

12 个工具

| 工具 | 用途 |
| virtuoso_status | 四层就绪检查：VM → sshd → 隧道 → CIW 能答出 1+1 |
| virtuoso_vm | VM + 隧道生命周期；up 是一键修复 |
| virtuoso_config | 持久化设置，下次调用时生效 |
| virtuoso_recover | 修复虚拟机 GUI，再用一次真实求值证明修好了 |
| virtuoso_windows | SKILL 窗口列表 + X11 窗口 id |
| virtuoso_screenshot | 把某个 Virtuoso 窗口截成 PNG，模型可以直接看 |
| host_window | 枚举 / 置顶 / 截取 Windows 宿主机窗口（VMware 控制台） |
| virtuoso_eval | 通过 stdin 执行任意 SKILL |
| virtuoso_run | 把耗时的虚拟机命令跑成后台任务 |
| virtuoso_drc | 把 Calibre DRC 输出解析成结构化 JSON |
| workspace_create | 注册一个工作区 |
| context_usage | 本会话的 token 预算（只读） |

完整的参数/输出 schema：TOOLS.md——从实时工具定义生成，所以不会和代码脱节。

写入闸门

lib/guard.js 装了一个全局工具守卫，拒绝会改动状态的 virtuoso_eval / virtuoso_run 调用，除非调用带上一个无状态、由 sha256 派生的 confirm token。

这套约定是从 harness 里读出来的，它决定了整个设计：守卫是同步的（不能等人），在 pre-execute 瀑布之后运行，只能拒绝——永远没法强行放行某个调用。所以设计是：

- 只读调用永不过闸。 dbOpenCellViewByType(… "r")、cv~>shapes、sleep; echo 原样通过——否则闸门会把你训练成不看内容就粘贴 token。
- 失败即拒绝。 读不到沙箱策略，守卫就拒绝。
- confirm: true 会被明确拒绝。 这只是走个形式，不算知情同意。
- danger-full-access 会弃权，因为用户已经授予完整写入权限——并且 virtuoso_status 会报告 enforcedNow，所以这道关卡的状态可观测。

已在四种情况下实测验证：拒绝 → token → 放行、token 错误、只读豁免、完整权限下弃权。

验证结果

想看图文版——截图，以及仍未验证事项的完整清单——见 RESULTS-SHOWCASE.md。

DSH_NMOS/dsh_nmos15 单元，跑在真实的 smic18ee SMIC 0.18 µm 工艺上：

| | 结果 |
| DRC | 393 项检查，6 项违规——全是密度规则，几何违规为零 |
| LVS | CORRECT——N=4 EP=4，M0 S G D B <model> L=0.18um W=1.2um |
| 保护环 | 四边 P+ 边框，通过栅格化并统计孔洞证明环路闭合 |
| 迭代次数 | 22 → 24 → 35 → 36 → 18 → 16 → 13 → 7 → 6 |

剩下 6 项是密度规则（PD.、MIM_8a）：一个孤立的 3.7 × 4.5 µm 器件，无法满足 <rv> 金属密度目标。整芯片的密度合规性尚未验证。这 6 项检查仍然未达标——不是豁免——这里也不声称任何东西 DRC 干净或可以流片。

未达成，并如实记录：

- PEX / 寄生提取。 xRC 规则是完整的，但随附的 deck 是为 Calibre xRC v2009.3 写的，已安装的 v2015.2 会以 Tcl 解析错误拒绝它。见 PEX-STATUS.md。用未修改的 deck 做了对照实验，排除了编辑器出错的可能。
- 多指 / 共质心匹配、布局布线、时钟树、电源网格。

文档地图

这个项目既记录了什么能跑通，也记录了什么出了错。出错的部分才是有意思的。

| 文档 | 内容 |
| RESULTS-SHOWCASE.md | 看结果从这里开始：达成了什么、截图、以及哪些仍未验证 |
| HISTORY.md | 时间线、bug 台账，以及那些已撤回的判断 |
| AGENTS.md | 项目记忆：路径、环境事实、排查顺序 |
| LAYOUT-AUDIT.md | 手写几何审计 → 发现 DRC 才是权威 |
| DRC-RESULTS.md | 第一次真正跑 Calibre：393 项检查，22 项违规 |
| SKILL-FIXES-AND-LVS.md | 三处 SKILL 方法错误，首次 LVS 通过 |
| NMOS-FINAL.md | 把器件收敛到只剩密度违规 |
| WELLS.md | 阱实验：P 阱是推导出来的，N 阱需要 pickup |
| RING-AND-CONNECTIVITY.md | 测量连通性：8 个孤岛，加环修好 3 个中的 1 个 |
| RING-CLOSED.md | 闭合环；为什么只有截图才暴露出它其实是实心条 |
| PEX-STATUS.md | 为什么寄生提取在这里跑不起来 |

三项值得一读的发现

1. 本应是环的防护环，实际却是一根实心条。 四个矩形在 y 方向重叠，填成了一整块。
没有哪条 DRC 规则写着「环必须留孔」，连通性分析把它算作一个元件，判定通过。一张截图立刻暴露了问题。 修复办法是按 10 nm 栅格化这些形状，再数封闭孔洞——这是肉眼能做的检查，现在自动化了。

2. Virtuoso 6.1.7 不支持前缀算术。 (- x d) 会触发加载错误，报错位置指向包装器的末尾，离出错点十万八千里。中缀写法（x - d）正常。为此耗掉了六轮排查。

3. procedurep 在这里探测不了内置函数。 对 geOpen 它返回 nil，而 geOpen 明明能用；errset 又把「没有这个函数」和「拒绝执行」都压成同一个 nil。基于这些探测得出的每个结论都得重新推导。

环境要求

- Cadence Virtuoso，需有合法授权安装（本项目基于 6.1.7-64b 开发）
- 一台 Linux 客户机，可通过免密 SSH 访问，运行在 VMware 或类似环境里
- 一个可绑定的工艺库
- Calibre，用于 DRC/LVS（可选；没有它插件也能驱动 Virtuoso）
- Node.js（插件只用 Node 内置模块——无需 npm install）
- DeepSeek Harness

没有 Virtuoso 和 PDK，这个插件就没有可驱动的对象。之所以发布它，是因为这套方法——把不透明的 EDA 工具变成可编程、可验证、有文档的接口——可以迁移到任何带脚本层的工具上。

安装插件

from the DSH checkout
node tools/virtuoso.mjs config-set vmrun="C:\path\to\vmrun.exe"
node tools/virtuoso.mjs config-set vmx="D:\path\to\guest.vmx"
node tools/virtuoso.mjs config-set guestIp=192.168.1.50
node tools/virtuoso.mjs config-set sshUser=youruser
node tools/virtuoso.mjs health # proves the CIW answers

然后把 dsh-plugin-virtuoso-layout/ 复制到 DSH 配置档的 node_modules/ 下，重启 DSH。改动 lib/.js 需要重启（HMR 只监听补丁文件）。

没有虚拟机时如何验证

node .validate/plugin-test.mjs # registers all 12 tools against a mock ctx
node .validate/guard-test.mjs # the write gate: classification / policy / registration
node .validate/context-test.mjs # token-meter contract, 50 checks
node .validate/job-test.mjs # background-job payload, 8 checks
node .validate/hint-test.mjs # error-message mapping
node .validate/paren-check.mjs f.il # SKILL paren balance

致谢

清华大学

没有 RAMIC Bridge 这层 SKILL，这个项目就不会存在，而它来自清华大学。

virtuoso-bridge-lite（MIT）由张智帅、李欣恬、孙楠和卢杰完成——这是清华大学孙楠教授课题组的工作，该课题组的研究覆盖模拟与混合信号 IC 设计以及围绕它的 EDA 自动化。ramic_bridge.il 这个文件让 socket 能在活的 CIW 里求值 SKILL——整个插件就靠这一个机制——是他们的成果。

衷心感谢清华大学和那个团队把它开源。清华大学，谢谢。

那个项目没有内置在这里；它是一个依赖项。请从它自己的仓库安装。

Mentor Graphics / Siemens EDA

Calibre，它的 DRC 和 LVS deck 让检查版图成为可能，而不只是看一眼。文档里引用的判定结论来自 Calibre，不是本项目。

Cadence

Virtuoso，以及插件驱动的 SKILL 语言和数据库 API。

关于第三方材料

本仓库不包含任何 foundry PDK、规则 deck，或含规则文本的 Calibre 输出。Foundry deck 是机密材料，只由 foundry 分发给授权客户。

这里的文档确实包含：deck 的规则标识符（GP_11a、SP_1、M1_6），以及每个几何决策背后的推理——哪条规则钉住了哪条边，改动它又破坏了什么。不包含：deck 自身的措辞，以及任何对规则限值的陈述。凡是本该出现限值的地方，都写成 X（在 Python 求解脚本里）或 <rv>（在正文和表格里），PDK 的器件模型名写成 <model>。

这种脱敏有两个局限，直说而不是暗示：

- 数值拿掉之后，solve-.py 就是模板，每个文件顶部都标明了这一点：它记录哪条规则驱动哪条边，在你用自己的 deck 填入数值之前无法运行。这是有意为之，不是缺陷。
- 数字仍会以我们自己的几何和算术形式出现。脱敏去掉了每一处同时点名规则和其限值的地方；它不会——也不能，否则就毁掉工程记录——去掉每一个恰好与某个限值重合的数字。

所以这不是开箱即用的复现包。 运行它需要授权的 Virtuoso、授权的 Calibre、从你的 foundry 获取的 PDK，以及针对你的安装环境编写的 DRC/LVS 调用脚本。这里的 scratch/drc/.sh 脚本是实际用过的临时脚本，带着本地路径和 deck 名；其中至少有一个没保留下来。复现结果意味着你自己补齐这些部分——而不是从我们这里拿到私有参数。

从你的 foundry 获取 deck。

License

MIT——全文在 LICENSE，包清单在 dsh-plugin-virtuoso-layout/package.json 里也写明了同样的事。

不能并入 MIT 文本的第三方声明——virtuoso-bridge-lite 的署名，以及哪些 foundry 材料被刻意省略——在 THIRD-PARTY.md。这样拆分不是吹毛求疵：GitHub 靠模板匹配文件来识别许可证，所以往 LICENSE 里追加段落会让它仓库报告写的是 NOASSERTION，不是 MIT。