Circuit

发布日期: 2026-07-24

更新日期: 2026-07-24

文章字数: 4k

阅读时长: 16 分

AI自动生成I/O ring, 从描述到版图

基于 https://github.com/chenzc24/t28-ioring，自动分析该项目

1. 项目定位

t28-ioring 不是 Linux 的 io_uring 项目，而是一套面向 TSMC 28 nm 工艺 IO Ring 自动生成与仿真验证 的 EDA Agent 工具。

它希望把以下流程自动化：

自然语言/结构化需求
        ↓
IO 类型与电压域识别
        ↓
生成结构化 JSON
        ↓
生成 Cadence SKILL
        ↓
Virtuoso 原理图与版图
        ↓
Calibre DRC/LVS/PEX
        ↓
自动生成测试平台
        ↓
Spectre 仿真与测量

项目被拆成两个相互独立的 Agent Skill：

t28-ioring-generator：负责 IO Ring 原理图、版图以及 DRC/LVS/PEX。
t28-ioring-simulator：负责符号导出、引脚分类、测试平台生成、Spectre 仿真和结果整理。

这是一个比较典型的“AI Agent + Python 流程编排 + Cadence SKILL + EDA 工具远程执行”项目。

2. 总体架构

项目的核心架构可以概括为：

本地 Agent / Python
    │
    ├── 需求解析、JSON生成、规则推导
    ├── 生成 SKILL、Spectre、Calibre 文件
    └── 读取并解析运行结果
    │
virtuoso-bridge-lite
    │
    ├── TCP Socket → Virtuoso 内部 SKILL daemon
    └── SSH → EDA Server
                  │
                  ├── Cadence Virtuoso
                  ├── Calibre DRC/LVS/PEX
                  ├── Spectre
                  └── Maestro/ADE

仓库本身不直接实现 Virtuoso 通信层，而是依赖另一个项目 virtuoso-bridge-lite。桥接层通过 TCP 与 Virtuoso 中加载的 SKILL daemon 通信，同时通过 SSH 上传脚本、执行 Calibre/Spectre 并下载结果。

这种分层是合理的：

t28-ioring 负责工艺和 IO Ring 领域逻辑；
virtuoso-bridge-lite 负责远程 EDA 基础设施；
Virtuoso/Calibre/Spectre 负责真实设计和验证。

3. 目录结构分析

t28-ioring/
├── README.md
├── AGENTS.md
├── CLAUDE.md
├── requirements.txt
├── _local/
│   └── site.yaml.template
├── tools/
│   ├── t28_config_check.py
│   ├── t28_config_export.py
│   └── t28_site_config/
└── skills/
    ├── t28-ioring-generator/
    │   ├── SKILL.md
    │   ├── scripts/
    │   ├── io_ring/
    │   ├── references/
    │   ├── skill_code/
    │   ├── calibre/
    │   └── T28_Testbench/
    └── t28-ioring-simulator/
        ├── SKILL.md
        ├── scripts/
        ├── sim_io/
        ├── references/
        ├── skill_code/
        └── templates/

仓库明确要求将 skills/ 或两个子目录分别注册为 Agent Skill，而不是把整个仓库当成一个 Skill。原因是生成和仿真具有不同的触发条件、配置、输出和失败处理机制。

关键目录职责

`_local/`

保存站点相关配置模板。

实际使用时需要创建：

_local/site.yaml

这个文件不提交到 Git，主要保存：

输出目录；
Cadence 安装路径；
cds.lib 路径；
Calibre 路径和规则文件；
Spectre 模型文件；
License 环境变量；
远程或共享文件系统模式。

项目刻意把所有 T28 站点配置集中在一个文件中，避免路径散落在 .env、C shell 脚本和 Python 文件里。

`tools/`

负责配置管理，而不是设计生成。

其中：

t28_config_check.py

用于检查路径、必填项和配置完整性。README 建议在长时间运行生成或仿真流程前先执行它。

`references/`

这是项目非常关键的一部分。

它保存的不是普通文档，而是供 Agent 读取的“领域规则”，例如：

T28 IO 单元选型；
信号分类；
IO 引脚连接规则；
电压域连接规则；
仿真引脚分类；
Spectre 测量配置规则。

这说明项目并非完全通过硬编码处理所有情况，而是采用：

Python确定性流程 + Agent语义判断 + Markdown领域规则

4. Generator 生成流程

生成器负责从设计需求生成 IO Ring。

README 给出的流水线为：

解析结构需求；
创建 draft intent JSON；
可选地打开草稿编辑器；
生成 semantic intent 和带引脚连接的图结构；
验证 JSON；
创建 confirmed config；
生成 schematic/layout SKILL；
在 Virtuoso 中执行 SKILL 并截取结果；
运行 DRC/LVS，可选运行 PEX。

可以将内部数据流理解为：

用户输入
  ↓
draft_intent.json
  ↓
semantic intent
  ↓
enriched pin-wired graph
  ↓
confirmed config
  ↓
schematic.il / layout.il
  ↓
Virtuoso database

其中可能的核心脚本包括：

scripts/enrich_intent.py
scripts/build_confirmed_config.py
scripts/generate_schematic.py
scripts/generate_layout.py
scripts/run_drc.py
scripts/run_lvs.py
scripts/run_pex.py

仓库把这些文件列为生成器核心、高风险代码。

Draft Intent

先把用户要求转换为较接近原始输入的数据结构，尽量保留：

原信号名；
信号顺序；
重复信号；
各边顺序；
ring 类型；
顺时针或逆时针顺序。

Semantic Intent

增加电气语义，例如：

{
  "name": "VIN",
  "class": "analog_io",
  "device": "PDB3AC",
  "voltage_domain": "VDDIB_VSSIB"
}

Enriched Graph

不仅记录 IO 类型，还建立具体连接关系：

Pad
 ├── PAD pin
 ├── core-side pin
 ├── VDD/VSS
 ├── ESD ring
 └── voltage-domain relation

Confirmed Config

将语义结果转换为生成引擎可以确定性使用的最终配置，避免 SKILL 生成阶段继续进行模糊推断。

这是整个项目比较好的架构点：让 AI 负责理解，让确定性程序负责落地。

5. IO 单元映射

仓库 README 中包含一组默认 T28 IO 单元映射：

信号类型	默认器件
模拟 IO/参考	`PDB3AC`
模拟电源提供端	`PVDD3AC` / `PVSS3AC`
模拟电源消费者	`PVDD1AC` / `PVSS1AC`
模拟 ESD Ring	`PVSS2A`
数字 IO	`PDDW16SDGZ`
数字 IO 备选	`PRUW08SDGZ`
低压数字 VDD/VSS	`PVDD1DGZ` / `PVSS1DGZ`
高压数字 VDD/VSS	`PVDD2POC` / `PVSS2DGZ`
数字 Corner	`PCORNER_G`
模拟/混合 Corner	`PCORNERA_G`

这些器件名称显然与特定 PDK 库绑定，并不是通用 TSMC 28 nm 标准名称。项目默认要求 cds.lib 中能找到 tphn28hpcpgv18 和 PAD 等库。

因此，这个项目不能简单理解为“安装后适用于任意 T28 PDK”。它更准确地说是：

针对某一套具体 T28 IO Library 和企业 EDA 环境建立的可配置自动化框架。

6. 版图生成可能采用的策略

根据目录划分和工作流，可以推断版图引擎主要处理以下问题：

用户给定信号顺序
       ↓
映射到 Pad Cell
       ↓
分配到 top/bottom/left/right
       ↓
计算方向和旋转
       ↓
插入 corner/filler
       ↓
处理 single/double ring
       ↓
建立电源与 ESD 连续性
       ↓
生成 SKILL 放置和连线代码

尤其需要处理：

上下左右四边不同的旋转方向；
顺时针/逆时针信号顺序；
Corner cell 选择；
单环和双环；
电源 Pad 到消费者 Pad 的域映射；
模拟和数字 ESD ring 的连续性；
Pad 数量不足时的 filler；
原理图和版图实例命名一致性。

仓库的 Agent 规则特别强调不能静默修改：

Device mapping；
Pin schema；
Corner/filler 行为；
Domain continuity；
DRC/LVS 规则解释。

这说明上述部分应当是项目最容易出错、也是最重要的算法区域。

7. Simulator 仿真流程

仿真器不是简单地打开 ADE，而是把 直接 Spectre 仿真 作为主要验证路径。

流程为：

从 DUT 导出 symbol 并重新分布引脚；
生成 pin_info.json 和 dut_context.json；
Agent 根据规则生成 pin_classifications.json；
Agent根据仿真规则生成 sim_config.json；
创建 {cell}_tb/schematic；
放置电源、激励、负载、PVSS、电流测量器件等；
导出 Spectre netlist；
生成顶层 deck.scs；
运行 Spectre；
解析测量结果并绘图；
将相同设置同步到 Maestro。

关键输出包括：

pin_info.json
pin_classifications.json
sim_config.json
dut_context.json
result.json
spectre/netlist.scs
spectre/deck.scs
spectre/spectre.out
measurements.json
sim_run_result.json
plots/

为什么不把 Maestro 当作主要结果来源

仓库明确规定：

直接 Spectre 输出 = 验证源
Maestro = 同步和可视化界面

这是一个很好的工程选择，因为 Maestro GUI 状态：

难以自动复现；
容易残留旧配置；
不利于 CI；
不便于解析；
容易发生 GUI 和实际 deck 不一致。

项目规定应主要检查：

sim_run_result.json
measurements.json
plots/
spectre/spectre.out

而不是依赖 Maestro 当前显示状态。

8. Pin Classification 的作用

仿真器需要先知道每个 DUT Pin 的电气角色，例如：

analog_input
analog_output
digital_input
digital_output
power
ground
reference
high_voltage_supply
low_voltage_supply
internal_bias

随后才能决定添加何种测试平台元件：

Pin 类型	可能添加的测试元件
Analog input	DC、pulse、sine 或 PWL source
Digital input	VPULSE
Analog output	电容或电阻负载
Digital output	数字负载或电容
VDD	DC voltage source
VSS	0 V source或地
Power consumer	对应 domain supply
Current measure	串联零伏源或特定测量支路

项目强制要求 Agent 真实读取 pin_info.json 和规则文档，再写入分类结果；不建议完全跳过这一语义步骤。

这个设计提高了灵活性，但也是结果可信度的一个风险点：引脚分类错误会直接导致测试平台错误。

9. 配置与运行环境

这个项目运行门槛较高，需要：

Python 3.9 或更高版本；
virtuoso-bridge-lite；
Cadence Virtuoso；
TSMC 28 nm PDK；
Calibre；
Spectre/MMSIM；
Maestro/ADE；
EDA 服务器上的 csh；
可用的 Cadence 和 Calibre License。

配置大致如下：

project:
  output_root: ...

generator:
  draft_editor: on
  layout_editor: off

bridge:
  fs_mode: remote
  disable_control_master: false

cadence:
  cds_lib_28: ...
  ic_root: ...
  mmsim_root: ...

calibre:
  mgc_home: ...
  pdk_layermap_28: ...
  lvs_include_28: ...

spectre:
  io_model_include: ...
  core_model_include: ...
  core_sections: ...
  lm_license_file: ...
  cds_lic_file: ...

桥接服务器的用户名、主机和 SSH 信息不放在这里，而由：

virtuoso-bridge init user@eda-server

写入：

~/.virtuoso-bridge/.env

这种分离可以避免将连接凭据混入工艺配置。

10. Remote 与 Shared 模式

项目支持两种文件传输方式。

Remote 模式

适用于：

本地 Windows；
本地和 EDA 服务器没有共享目录；
通过 SSH 连接服务器。

流程是：

本地生成脚本
   ↓ SSH上传
/tmp/vb_t28_calibre...
   ↓ 服务器运行
生成报告
   ↓ SSH下载
本地 output

Shared 模式

适用于：

本地 Linux；
本地与 EDA 服务器挂载同一个 NFS；
两端能看到相同文件路径。

这种模式避免上传下载，但要求路径在本地和服务器上保持一致。项目可以自动判断模式，也允许通过 bridge.fs_mode 强制指定。

11. 项目的优点

11.1 数据分层比较清楚

项目没有从自然语言直接生成最终 SKILL，而是经过：

draft → semantic → enriched → confirmed → SKILL

这有利于：

调试；
人工确认；
JSON schema 检查；
失败重跑；
保存中间语义；
防止大模型输出直接破坏版图。

11.2 将 AI 判断与确定性生成分离

AI 主要用于：

信号分类；
电压域理解；
Pin 意图判断；
仿真配置生成。

Python和SKILL负责：

坐标；
实例放置；
连线；
文件生成；
工具调用；
结果解析。

这是 EDA Agent 比较合适的实现方向。

11.3 验证闭环较完整

不是只生成版图，而是包含：

原理图
版图
截图
DRC
LVS
PEX
测试平台
Spectre仿真
测量
绘图

因此它更接近完整 IO Ring flow，而不是单纯的 SKILL 代码生成器。

11.4 强调最早安全修复点

项目规定发生问题时，优先按以下顺序修复：

semantic intent；
本地路径配置；
confirmed config；
重新生成 SKILL；
最后才修改核心引擎。

这可以减少因单个输入问题而污染通用代码的风险。

11.5 输出目录设计合理

输出按运行时间组织：

generated/<timestamp>/
simulation/<timestamp>/
drc/
lvs/
pex/

同时用 .latest_run 标记最近一次仿真。这种设计有利于追踪历史和比较多个运行结果。

12. 项目的主要风险与不足

12.1 与具体 PDK 耦合很深

器件名称、Pin schema、Calibre deck、layer map 和模型文件都依赖具体站点。

即便同样叫 TSMC 28 nm，不同公司环境可能存在：

不同 IO 库版本；
不同 cell 名称；
不同 pin 名称；
不同 Calibre rule deck；
不同 layer map；
不同 PDK wrapper；
不同 cds.lib 组织方式。

因此移植时最可能出问题的是：

lydevices_28.json
enrichment rules
SKILL device pin map
Calibre rule templates
Spectre model sections

12.2 Agent 语义结果缺少天然形式验证

例如大模型可能把：

VSSIB

错误分类为普通模拟输入，或者把：

D1

误认为数字输入而实际是输出。

JSON schema 只能验证结构正确，无法验证电气语义一定正确。建议增加：

基于命名规则的 deterministic lint；
供电与地成对检查；
Provider/consumer 闭合检查；
无驱动输入检查；
输出端误加电压源检查；
电压域冲突检查。

12.3 真正的端到端测试依赖昂贵环境

很多核心功能只有在真实环境中才能验证：

Virtuoso database；
IO PDK library；
Calibre license；
Spectre model；
EDA server；
SSH；
Cadence license。

因此普通 GitHub CI 很难覆盖完整流程。

仓库虽然提供 golden output，但 golden 文件只能验证“输出是否和历史一致”，不能完全证明结果在当前 PDK 中 DRC/LVS 正确。

12.4 自动 DRC/LVS 修复存在风险

如果系统依据 DRC/LVS 文本自动修改布局，容易发生：

修掉一个 DRC，引入另一处 DRC；
为过 LVS 而错误短接；
通过几何补丁掩盖语义错误；
只适配某版 rule deck；
修复循环不收敛。

好在仓库把这一流程标记为高风险，并要求限制 repair loop，但具体安全性仍取决于实现。

12.5 缺少明显的开源 License

从当前仓库首页信息看，没有显示许可证文件。

这意味着即便仓库公开，也不能默认其代码可自由复制到商业项目中。使用前最好由作者明确补充 MIT、Apache-2.0 或其他许可证。

12.6 配置项仍然较多

虽然已集中到 site.yaml，但首次部署仍要正确配置：

Bridge；
SSH；
Cadence；
MMSIM；
Calibre；
PDK；
模型；
License；
NFS/Remote 模式；
IO 库。

对于新用户而言，故障定位仍然较复杂。

13. 最值得阅读的代码顺序

要深入理解该项目，建议按以下顺序阅读。

第一阶段：理解流程合同

README.md
AGENTS.md
skills/t28-ioring-generator/SKILL.md
skills/t28-ioring-simulator/SKILL.md

这里定义了 Agent 应按什么顺序执行，以及哪些操作不能跳过。

第二阶段：理解 IO 语义

generator/references/enrichment_rules_T28.md
generator/references/T28_Technology.md
simulator/references/pin_classification.md
simulator/references/sim_config_rules.md

第三阶段：理解 Generator

scripts/enrich_intent.py
scripts/build_confirmed_config.py
scripts/generate_schematic.py
scripts/generate_layout.py
io_ring/
skill_code/

重点关注：

Signal → Device 映射；
Pin mapping；
side ordering；
orientation；
corner/filler；
power/ESD continuity；
SKILL 模板生成。

第四阶段：理解验证

scripts/run_drc.py
scripts/run_lvs.py
scripts/run_pex.py
calibre/

重点关注：

Runset 如何构造；
GDS/OASIS 如何导出；
LVS source 如何生成；
Exit code 如何解析；
报告如何判定 pass/fail；
Repair loop 上限。

第五阶段：理解 Simulator

sim_io/pin_types.py
sim_io/flow.py
sim_io/sim/
sim_io/maestro/
scripts/tb_builder.py
scripts/spectre_runner.py

重点关注：

pin_classifications.json schema；
source/load placement；
Spectre deck wrapper；
model include；
measurement expression；
仿真结果解析。

14. 一次完整运行的概念示例

用户输入：

生成一个 4×4 单环 IO Ring，逆时针排列。

VIN、VCM 是模拟 IO。
VDDIB/VSSIB 是模拟电源。
D1~D4 是数字输出。
VIOL/GIOL 是低压数字电源。
VIOH/GIOH 是高压数字电源。

生成器可能得到：

{
  "ring": {
    "pads_per_side": 4,
    "type": "single",
    "order": "counterclockwise"
  },
  "signals": [
    {"name": "VIN", "type": "analog_io", "device": "PDB3AC"},
    {"name": "VSSIB", "type": "analog_vss_provider"},
    {"name": "VDDIB", "type": "analog_vdd_provider"},
    {"name": "VCM", "type": "analog_io"},
    {"name": "D1", "type": "digital_output"},
    {"name": "D2", "type": "digital_output"}
  ]
}

然后生成：

create_schematic.il
create_layout.il

在 Virtuoso 中产生：

LLM_Layout_Design/IO_RING_4x4_mixed/schematic
LLM_Layout_Design/IO_RING_4x4_mixed/layout

随后：

DRC → LVS → 可选 PEX

仿真器再导出 symbol，生成：

IO_RING_4x4_mixed_tb/schematic

并执行：

spectre deck.scs

最终给出：

measurements.json
plots/
sim_run_result.json

15. 综合评价

我对这个项目的总体判断是：

方面	评价
项目目标	明确，聚焦 T28 IO Ring 自动化
架构设计	较好，AI语义与确定性生成分离
EDA流程覆盖	很完整
工艺可移植性	一般，与特定 PDK/IO 库耦合较深
可复现性	取决于 EDA 服务器和 PDK
自动验证	较强，包含 DRC/LVS/Spectre
自动修复风险	较高，需要严格保护
普通用户部署难度	高
商业使用清晰度	受缺少 License 影响

它的核心价值不只是“自动画一个 IO Ring”，而是建立了一套：

从自然语言需求，到结构化电气意图，再到 Cadence 数据库、物理验证和电气仿真的 Agent 驱动闭环。

从研究或内部工程原型角度看，这个方向非常有价值。若要变成稳定的生产工具，下一步最重要的是：

加强语义 JSON 的电气 lint；
建立更多不同 IO 组合的回归测试；
对 SKILL 生成做单元测试；
把 PDK 相关规则进一步抽象成 technology adapter；
对自动 DRC/LVS 修复设置严格白名单；
补充 License、版本锁定和 CI 测试说明。

chatgpt

https://elike.top/posts/7d05/

本博客所有文章除特別声明外，均采用 CC BY 4.0 许可协议。转载请注明来源 chatgpt !

Analog Circuit AI I/O

本篇

AI自动生成I/O ring, 从描述到版图

基于 https://github.com/chenzc24/t28-ioring, 分析该库的内容

2026-07-24 Circuit

Analog Circuit AI I/O

50MHz VAF-RCOSC Design Guide

基于 Tokunaga et al., JSSC 2010, Vol.45, No.6 "An On-Chip CMOS Relaxation Oscillator With Voltage Averaging Feedback", 从论文 14MHz 原型缩放到 50MHz，面向 ±1% 时钟精度目标

2026-06-26 Circuit

RCOSC Analog Circuit