内容
# Vibe-IC
**基于Claude的AI原生IC设计，从自然语言意图到验证硅。**
[](LICENSE)
[](https://github.com/vibeic/awesome-open-ic)
[](vibe-ic-marketplace/README.md)
[](vibe-ic-marketplace/plugins/vibe-ic/mcp-eda/README.md)
> **状态：v1.4 — 成熟，基准测试强化。** `vibe-ic`插件是产品：一次安装捆绑并自动注册MCP服务器、IP目录和基准测试框架。安装一次，即可使用自然语言进行设计。每个功能都由确定性检查器控制，并不断针对开源IC设计基准测试（见下文**基准测试结果**）进行强化。
Vibe-IC是Claude Code插件 + Model Context Protocol（MCP）服务器，旨在连接大型语言模型与真正的开源EDA工具，使设计师能够驱动整个IC流程 — 从一段意图到L1-L27设计文档、RTL、FPGA验证和tape-out签发 — 使用自然语言，每一步都由确定性检查器控制（无制造，无幻觉PASS）。
---
## 目录结构
```
.
├── vibe-ic-marketplace/ Claude Code插件市场（+合作伙伴插件）
│ └── plugins/vibe-ic/ ★ vibe-ic插件 — 一次安装 = 所有功能：
│ ├── skills/ programs/ 技能 + 确定性程序
│ ├── agents/ commands/ hooks/
│ ├── mcp-eda/ 捆绑的MCP-EDA服务器 — 开源EDA工具
│ │ + 实验室设备包装器，自动注册 via .mcp.json
│ ├── ip-catalog/ 开源IP目录（清单）
│ └── benchmark/ 基准测试框架 + 注册表
├── IP/ 开源核心git子模块（serv · ibex · sha256 · opentitan）
├── benchmark-data/ 基准测试数据集（6.8 GB）— 见下文“The benchmark corpus”
│ ├── ic/ 7个规范基准IC，从文档 → RTL → GDS
│ ├── evaluation/ 8个开源基准 / 对比评估集
│ └── datasets/ 供应商基准数据集
├── benchmark_external/ 外部基准测试框架说明（CVDP合法输入定义）
├── tools/ 仓库开发/CI工具（第二个pytest树）
├── docs/ 仓库级指南 — INSTALL.md · 治理运行手册
├── LICENSE Apache-2.0
├── NOTICE 第三方属性
├── CONTRIBUTING.md 如何贡献
├── CODE_OF_CONDUCT.md 贡献者契约v2.1
└── SECURITY.md 漏洞报告
```
---
## 快速开始
### 1. EDA工具链（Docker）
所有开源EDA工具（Yosys、OpenROAD、KLayout、Magic、ngspice等）都在名为`vibeic-eda`的Docker容器中运行（MCP服务器通过`EDA_CONTAINER`期望的名称）。**推荐 — 增强的fork镜像**（修补OpenROAD / yosys / ngspice / magic / netgen / iverilog / klayout与gatekeeper-verified FAIL→PASS修复；`tools/vibeic-eda/FIX_STATUS.md`中的记分板）：
```bash
docker pull ghcr.io/vibeic/vibeic-eda:0.2.23 # 或构建：docker build -t vibeic-eda:0.2.23 tools/vibeic-eda
docker rm -f vibeic-eda 2>/dev/null || true # “名称已被占用”？先删除旧容器
docker run -d --name vibeic-eda \
-v "$HOME/AI_IC_design:$HOME/AI_IC_design:rw" \
-v "$HOME/AI_IC_design:/foss/designs:rw" \
ghcr.io/vibeic/vibeic-eda:0.2.23 --skip sleep infinity
docker exec vibeic-eda yosys --version # 健康检查 — 应该打印版本号
```
备用：`docker pull hpretl/iic-osic-tools:latest`（以`vibeic-eda`命名运行）。如果已经运行较旧的标签？无需重新输入挂载：`tools/vibeic-eda/restart-eda.sh 0.2.19`。参见**[docs/INSTALL.md](docs/INSTALL.md)**了解所需的绑定挂载（第3阶段需要身份挂载）。
镜像标签由一行代码`tools/vibeic-eda/VERSION`固定；`tools/vibeic-eda/sync_image_version.py --check`如果安装文档与之偏离，则会使构建失败，因此上面的标签永远不会过时。
**PDKs.** 流程通过`plugins/vibe-ic/programs/pdk_registry.json`解析PDKs：
| PDK | 说明 |
|---|---|
| `sky130A` · `gf180mcuD` · `ihp-sg13g2` | 开源代工厂PDKs — 真实的签发目标 |
| `nangate45` · `asap7` | **通用/预测研究和教育启用** — 完整的LEF + Liberty + GDS，因此可以进行综合/PnR/CTS/STA和面积-时间比较，但每个都标记为`tapeout_capable=false`在注册表中：没有真正的代工厂，没有可制造的层堆栈，运输的DRC套件是教育规则检查，**不是**签发 |
| `custom_auto_detect` | 您自己准备的PDK，自动从其磁盘布局中检测 |
**商业PDK**仅作为一种机制支持：解析器读取`VIBEIC_COMMERCIAL_PDK_ID`环境变量（或私有的、gitignore的用户配置），并且在该仓库中从不携带供应商标识符 — 见`plugins/vibe-ic/programs/_commercial_pdk.py`。插件中不捆绑任何PDK。
### 2. 安装`vibe-ic`插件（一步）
将此仓库添加为市场并安装插件。这**还捆绑并自动注册MCP-EDA服务器** — 不需要单独的`claude mcp add`:
```bash
claude plugin marketplace add vibeic/vibe-ic
claude plugin install vibe-ic
```
> 捆绑的MCP-EDA服务器在插件的`.mcp.json`中声明，并在安装时自动注册；其npm依赖项在首次运行时通过插件的`post_install`钩子安装。
> 在交互式Claude Code会话中，相同的两个命令是`/plugin marketplace add vibeic/vibe-ic`和`/plugin install vibe-ic@vibe-ic-marketplace`。
### 3. 设计某事物
```bash
claude "设计一个温度传感器IC：I2C接口，12位，警报输出，SOIC-8封装。"
```
Claude将调度适当的技能，调用MCP-EDA工具，并发出L1-L27设计文档 + RTL + 验证位流。
可选的全实验室集成：
- **Intel Quartus Prime Lite**（免费）— FPGA综合/位流烧录
- Cyclone-/MAX10系列FPGA板（我们在Terasic DE10-Lite上测试）
- USB示波器（我们在Keysight DSO-X 3014T上测试）
- 自定义协议测试仪或任何HID类USB设备（`vibe-ic-marketplace/plugins/vibe-ic/mcp-eda/src/devices/tester/`中的驱动程序模板）
---
## 设计流程概览
```
自然语言意图
│
▼
┌────────────────────────────────────┐
│ 阶段1（文档/规格提取） │
│ L1-L27 JSON设计文档 │
└─────────────────┬──────────────────┘
▼
┌────────────────────────────────────┐
│ 阶段2（RTL + 验证 + │
│ FPGA原型） │
│ Yosys lint → Icarus sim → │
│ SymbiYosys formal → 覆盖率 → │
│ Quartus综合 → SOF → 板载 │
│ 协议验证 │
└─────────────────┬──────────────────┘
▼
┌────────────────────────────────────┐
│ 阶段3（签发 + tape-out） │
│ OpenSTA → DFT → OpenROAD PnR → │
│ KLayout DRC → Netgen LVS → GDS │
└────────────────────────────────────┘
```
**每个项目都从第1阶段开始。** 两个入口路径 — 路径A（现有设计文档）和路径B（自然语言提示/对话）— 都汇聚到同一个通用交接点，即**L1-L27 JSON**设计文档集。第2阶段无法在没有它的情况下开始：规范流程门控硬要求第1阶段的`generated_docs/L*.json`在任何RTL被编写之前。有“跳到第2阶段”的入口 — L1-L27交接点使下游流程统一，无论设计如何指定。
对于**模拟和混合信号**设计，两个额外的阶段轨道与数字阶段交织：
- **模拟轨道 — A1-A9.** A1规格提取（第1阶段）→ A2拓扑选择 → A3网表 + 尺寸选择 → A4角扫描（第2阶段）→ A5布局 → A6每个块的物理验证 → A7布局后重新模拟 → A8硬宏生成 → A9硅/硬件验证（第3阶段）。
- **混合信号轨道 — M1-M4**（第3阶段）。M1模拟+数字GDS合并 + 宏放置 → M2电源域 / 级移位器 /隔离检查 → M3 AMS共模拟 + 接口信号完整性 → M4顶级PV签发。
在整个过程中，**规范流程合规门控**验证每个必需步骤实际运行（无跳过阶段，无豁免签发），并且**芯片无关源保护**将专有IC名称排除在公共源树之外。
---
## 基准测试结果
Vibe-IC不断针对开源IC设计基准测试进行强化。公布的数字衡量**确定性运行链可以做到什么**（程序优先 — `vibe_ic_one_shot_runner.py`→ 阶段1/2/3 + 插件程序 + MCP-EDA），而不是原始LLM使用相同的工具可以做到什么。每次运行都披露任何开源↔商业工具替换，并遵循[开源基准测试方法论](vibe-ic-marketplace/plugins/vibe-ic/skills/open-benchmark-methodology/SKILL.md)。
最新清洁室运行（2026-07-12）：**Claude Fable 5**驱动插件**v1.3.88**在分叉的vibeic-eda工具链上（每次运行的RESULT.md都命名确切的镜像）。CVDP数据来自早期的活动，Claude Opus 4.8（v1.2.63）；每个分数都命名其模型。
| 基准测试 | 结果 | 说明 |
|---|---|---|
| **NVIDIA CVDP**（非智能代码生成，无商业） | **243/302 = 80.46%** 官方合规盲目通过@1 *(Opus 4.8, v1.2.63)* | **仅限提示+上下文** — 确定性求解器仅读取`input.prompt` + `input.context`; 隐藏的测试框架（`.env`, cocotb测试台）和黄金解决方案是禁止访问的，由回归守卫证明发出的是字节标识符，与有无它们一致。 在固定的`cvdp-sim`镜像中使用官方`run_benchmark.py`进行评分。 |
| **RTLLM v2.0** | **49/50 = 98%** 盲目通过@1 (**49/49 = 100%** 排除1个已证实的上游数据集缺陷） *(Fable 5, v1.3.88)* | 规格到RTL，运行驱动（形状B），§4.05-盲目，iverilog评分；单次47/50 = 94%，在**一个**盲目闭环回合后收敛。 剩余的（`ring_counter`）是一个黄金失败自己的测试台 — 设计RESULT条目，不是沉默下降。 |
| **VerilogEval-v2** | **153/156 = 98.08%** 盲目通过@1，**单次** *(Fable 5, v1.3.88)* | 规格到RTL，§4.05-盲目，iverilog评分；156/156个问题由确定性求解器发出。 3个残留物是文档缺陷/规格模糊 — 评分位于缺陷地板，没有闭环回合。 |
| **VerilogEval-Human** | **153/156 = 98.08%** 盲目通过@1，**单次** *(Fable 5, v1.3.88)* | 代码完整（iccad2023），§4.05-盲目，iverilog评分；156/156个确定性发出。 |
> **诚实高于分数。** 合规性是插件的结构性不变性，而不是运行时便利 — 没有基准测试运行读取隐藏的框架或黄金参考来提高数字，并且新的干净室重新运行再现已发布的数字。 工具替换（Synopsys VCS → Icarus, Design Compiler → Yosys+OpenROAD, …）在每个`RESULT.md`中公开。
---
## 基准测试数据集 — `benchmark-data/`
上述每个数字都以此仓库中的文件为后盾。`benchmark-data/`为6.8 GB，分为三个部分：
| 子树 | 大小 | 它包含什么 |
|---|---|---|
| [`ic/`](benchmark-data/ic) | 5.0 GB | 7个规范基准IC，从文档 → RTL → GDS |
| [`evaluation/`](benchmark-data/evaluation) | 994 MB | 8个评估集 — 开放基准测试运行 + 第1阶段对齐扫描 |
| [`datasets/`](benchmark-data/datasets) | 838 MB | 供应商基准测试数据集（输入，不是我们的输出） |
两个受众，两个入口点。 如果您**检查已发布的声明**，请阅读相关目录顶部的`RESULT.md` / `BENCHMARK_VERIFICATION_REPORT.md` — 每行都命名证明它的工件，因此声明可以追踪到文件而不是被信任。 如果您**重新运行**，则只取`input/`子树；其他所有内容都是输出，并且会重新生成。
### `ic/` — 7个规范基准IC
我们在[`ic/METHODOLOGY.md`](benchmark-data/ic/METHODOLOGY.md)中的纠正协议下将IC推送到**整个**流程，其硬规则是输入是**精选的设计文档** — 无RTL，无参考网表 — 因此运行不能悄悄复制它被评分的答案。
| IC | 它是什么 |
|---|---|
| `spm` | 可配置N位串行并行整数乘法器 |
| `sha256` | SHA-256哈希核心 |
| `subservient` | 位串行RISC-V核心 |
| `ibex` | 32位RISC-V CPU核心 |
| `opentitan_aes` | OpenTitan家族中的AES模块 |
| `caravel_user_project` | Caravel SoC框架的用户项目 |
| `u_hawaii_adc` | **模拟/混合信号** — 运行模拟A1-A9轨道（规格 → 拓扑 → 尺寸 → 角扫描 → 布局 → 布局后重新模拟 → 硬宏）而不是数字第3阶段轨道 |
典型的IC目录：```
ic/<name>/
├── input/docs/ 唯一的合法输入 — 精选的设计文档
├── phase1/generated_docs/L*.json 第2阶段所需的L1-L27交接点
├── phase2/ 生成的RTL，lint，模拟
├── phase3/ 综合 · PnR · DRC/LVS · GDS（模拟/适用于AMS轨道）
├── reports/ 每阶段的JSON + 覆盖率 + 阶段审计
├── sim/ 模拟工件
├── RESULT.md 判决，每个阶段都有证据路径每行
├── SOURCE_MANIFEST.md 任何重用内容的来源
└── clean_run_*/ 自包含目录每个干净室重新运行
```
`clean_run_*/`就是为什么树很大而且故意这样：新的运行永远不会覆盖旧的判决，因此回归保持可见而不是被静默替换。
### `evaluation/` — 8个评估集
公开基准测试运行 + 对发齐次扫描
| 集 | 大小 | 它是什么 |
|---|---|---|
| `cvdp` | 280 MB | NVIDIA CVDP活动 — 合规性强化的重新运行，造就了243/302的数字 |
| `cvdp-open-v1252` | 13 MB | 每问题CVDP工作目录来自开放（智能）分割 |
| `verilogeval_v2` | 164 MB | VerilogEval-v2规格到RTL运行 |
| `verilogeval_human` | 114 MB | VerilogEval-Human代码补全运行 |
| `verilogeval_machine` | 34 MB | VerilogEval-Machine运行（早期活动） |
| `rtllm` | 55 MB | RTLLM v2.0规格到RTL运行 |
| `phase1_parity` | 334 MB | **87协议第1阶段对齐扫描** — 确定性第1阶段引擎是否提取与AI参考相同的协议事实？一个目录对应一个协议，每个目录包含引擎的`phase1/generated_docs/L*.json`和`reports/`下的提取覆盖率/对齐报告 |
| `interconnect` | 48 KB | 芯片间互连基准测试**锚点** — 带有固定上游提交和许可证的清单；上游RTL按需获取，不会预先存储（参见其`README.md`） |
旁边放置的是交叉切割分类账 — `FAIL_CASE_LEDGER.md`，`RESIDUAL_DEFECTS.md`和活动特定的`RESULT_*.md` — 记录失败和已知的数据库缺陷，而不是仅仅记录胜利。
### `datasets/` — 供应商输入
`cvdp-benchmark-dataset`（838 MB）：上游CVDP问题集，以发货的`.jsonl`格式存储，每个数据集版本和分割（`v1.0.2` … `v1.1.0`; 智能/非智能 × 代码生成/代码理解 × 商业/非商业）。这是**我们不编写的输入** — 保留在树中并固定版本号，以便发布的分数可以针对确切的分割进行重现。
---
## 代理角色与签入治理
Vibe-IC 具有 **两层贡献层** —— 请保持它们分开：
- **第 1 层 — 公共贡献模型（外部贡献者遵循的模型）。**
如果您发现一个错误，您可以 **提交积压（报告，无代码）** 或 **打开拉取请求（PR，有代码）**。这两种路径都是有效的，适用于不同的情况（仅报告与报告和修复）；前者并未取代后者。**仓库守门员（repo-gatekeeper）** —— 唯一的维护者身份 —— 对积压事项进行分类，并审查 + **合并 PR 到下一个版本**。外部贡献者 **不具备维护者角色**，**不能直接推送到 main 分支**；请参见 [CONTRIBUTING.md](CONTRIBUTING.md)。
- **第 2 层 — 维护者内部改进阶段的快捷方式。** 在维护者构建插件期间，它直接修复并 **直接推送** 到 `main` 分支，同时保留所有质量 **关卡（gatekeeper_review、MERGE_OK 和对抗性 §4.05 无泄漏审查 + 单调版本号更新）**；只有 PR **仪式（ceremony）被省略**。这是内部收敛的快捷方式，**不是公共模型**。
角色按场景分隔 —— 最重要的是 —— **根据每个角色可以签入（git commit）的内容**。治理规则是：**只有维护者角色（仓库守门员）可以编辑插件或 MCP 服务器。** 任何其他角色发现问题时，都会将其反馈给上游 —— **积压报告** 或 **无版本号的 PR**，并附上修复方案 —— 然后由守门员解决并将其合并到插件/MCP 中。**仓库守门员** 既可以编写确定性的、与芯片无关的修复程序，又可以控制每个更改的关卡；质量由 **关卡** 保证，而不是由作者≠批准者分离。
| 代理 | 场景 | 可以签入到 | 插件 | MCP | 发现问题时 |
|---|---|---|---|---|---|
| **现场代理** | 一般使用 / 审计 | 仅限 `community/backlogs/` | ❌ | ❌ | → 积压 → 守门员合并 |
| **基准代理** | 维护者官方运行 + 终端用户本地运行 | `benchmark-data/`（插件/MCP 修复通过无版本号 PR，无混合） | ❌ | ❌ | → 无版本号 PR → 守门员合并 |
| **核心代理**（= 仓库守门员） | 维护者 | 所有内容（拥有插件 + MCP） | ✅ 唯一角色 | ✅ 唯一角色 | 解决积压 + 合并 PR → 修复插件/MCP |
| **IC 专家代理** | 第一阶段 — 技术审查 | 设计时，无仓库签入 | — | — | — |
- **MCP 服务器位于插件树下** (`plugins/vibe-ic/mcp-eda/`)，因此“不能触摸插件”已经涵盖了“不能触摸 MCP”。
- **基准代理** 运行 **基准评估**（开放基准通过 `/vibe-ic-benchmark`）和 **基准 IC**（规范 IC 通过 `/vibe-ic-all` → `/benchmark-verify`），并拥有 `benchmark-data/`。
- **现场代理** 只签入有机积压镜像。
- 该边界通过 **确定性关卡** 强制执行，而不是通过信任 —— `programs/agent_checkin_scope_guard.py --role <role> --staged`（退出 1 列出角色范围外的任何路径）。每个角色的章程位于 `plugins/vibe-ic/agents/<role>.md`；完整矩阵 + 捕获增强循环位于 [`AGENT_USAGE_GUIDE.md`](vibe-ic-marketplace/AGENT_USAGE_GUIDE.md)。
---
## 关键设计原则
1. **单代理 RTL 生成** — 多代理方法在子模块间存在端口命名漂移。
2. **L9 集成规范先于任何 RTL** — 子模块端口在单个规范位置定义。
3. **无存根模块** — 顶级实例化所有内容。
4. **真实基准夹具** — 每个遍历器 / 正则表达式 / 合并补丁必须附带真实世界文档形状夹具位于 `tests/fixtures/real_benchmark/` 下，而不是仅限于最小综合案例。
5. **确定性优于启发式** — 每个检查都是具有固定判决层级的 Python 程序（PASS / PASS_WITH_WAIVERS / FAIL），而非由 LLM 判断的“看起来不错”。
---
## 文档
- **插件概述和更改日志** — `vibe-ic-marketplace/README.md`
- **插件安装和技能** — `vibe-ic-marketplace/plugins/vibe-ic/README.md`
- **MCP-EDA 服务器和 EDA 工具** — `vibe-ic-marketplace/plugins/vibe-ic/mcp-eda/README.md` 和 `.../mcp-eda/INSTALL_GUIDE.md`
- **基准方法论** — `vibe-ic-marketplace/plugins/vibe-ic/skills/open-benchmark-methodology/SKILL.md`
- **基准 IC 协议**（什么是合法输入）— `benchmark-data/ic/METHODOLOGY.md`
- **六柱 IC 验证** — `vibe-ic-marketplace/plugins/vibe-ic/skills/benchmark-verify/SKILL.md`
- **EDA 分叉计分板和镜像构建** — `tools/vibeic-eda/README.md` 和 `tools/vibeic-eda/FIX_STATUS.md`
- **代理角色和治理** — `vibe-ic-marketplace/AGENT_USAGE_GUIDE.md`
- **贡献新 IC 类 / PDK / 门 / 技能 / 设备** — `vibe-ic-marketplace/docs/CONTRIBUTING_*.md`
---
## 相关仓库（`vibeic` 组织）
Vibe-IC 被刻意拆分为多个目的范围的仓库，位于 [github.com/vibeic](https://github.com/vibeic)，通过显式版本号合约连接在一起（此插件固定 `vibeic-eda` 镜像标签；`vibeic-eda` 固定每个分叉的 SHA）。此仓库 —— **插件** —— 是您安装的仓库。
```
11 个分叉的 EDA 工具 ──▶ vibeic-eda ──▶ vibe-ic ──▶ 您
（OpenROAD·yosys· （Docker 镜像） （此仓库： （Claude 代码）
ngspice·magic·netgen· 插件）
iverilog·klayout· │
cocotb·cocotb-coverage· ▼
pyuvm·sby — 每个都是真正的 vibe-ic-studio
分叉，跟踪上游） （网页控制界面）
```
- **[vibeic-eda](https://github.com/vibeic/vibeic-eda)** — 分叉的 + 修复的开源 EDA 工具链，作为 Docker 镜像提供。当分叉更改时重新构建，而不是当此插件更改时。
- **EDA 分叉** — 镜像从源代码构建的 11 个分叉，每个分叉都固定在 `tools/vibeic-eda/Dockerfile` 中的提交 SHA：OpenROAD、Yosys、ngspice、Magic、Netgen、Icarus Verilog、KLayout、cocotb、cocotb-coverage、pyuvm 和 SymbiYosys。Verilator 也被视为分叉，但无需自定义补丁。每个分叉都保留其 **独立** 仓库，以便可以拉取上游修复并将我们的修复贡献回去；它们永远不会被合并到此插件中。每个分叉的计分板：[`tools/vibeic-eda/FIX_STATUS.md`](tools/vibeic-eda/FIX_STATUS.md)。
- **[vibe-ic-studio](https://github.com/vibeic/vibe-ic-studio)** — 网页控制界面（平台 + 项目层），独立部署。
- **[Awesome Open IC](https://github.com/vibeic/awesome-open-ic)** — 精心策划的、MCP 感知的开放源代码 IC 工具、IP 芯片、PDK、基准和标准的地图（记录 MCP-EDA 是否已经封装每个）。
---
## 贡献
我们欢迎各种规模的贡献：错误报告、文档修复、新技能、新 EDA 工具包装、新设备驱动程序、新基准夹具。请在打开拉取请求之前阅读 [CONTRIBUTING.md](CONTRIBUTING.md) 和 [行为准则](CODE_OF_CONDUCT.md)。
对于安全漏洞，请参见 [SECURITY.md](SECURITY.md) —— 请 **不要** 公开问题。
### 安装 Git 钩子（一行）
```bash
tools/install-git-hooks.sh
```
`.git/hooks/` 不被跟踪，因此仓库的钩子在安装之前不会生效。安装程序会链接两个受跟踪的钩子，因此后续的 `git pull` 改进钩子会在无需重新安装的情况下生效；重新运行是幂等的，并且除非您传递 `--force`，否则它不会覆盖具有相同名称的预先存在的钩子。两个钩子都阻止专有 PDK 晶圆厂/SKU/工艺名称到达提交 **消息** — `commit-msg` 在创建提交时，`pre-push` 跨越推送范围内的每个消息。即是源文件守护程序无法看到的表面，因此这两个是互补的，您需要同时使用它们。详见 [tools/git-hooks/README.md](tools/git-hooks/README.md)。
---
## 许可证
Apache License 2.0 — 请参见 [LICENSE](LICENSE) 和 [NOTICE](NOTICE)。
此许可证与将 Vibe-IC 与开源 PDK（SkyWater、GF180MCU、IHP — 均为 Apache-2.0） 和开源 EDA 工具（Yosys — ISC；OpenROAD — BSD-3-Clause；KLayout — GPL-3.0 作为独立程序调用；Magic / netgen — 类似 MIT）捆绑在一起兼容。专利授予是明确的（Apache-2.0 §3）。
## IP 所有权和商业工具防火墙
**工具 vs 设计。** Vibe-IC 是一个 *工具*，而非 *设计*。您使用它生成的设计（RTL、网表、GDS、约束、测试向量）是 **您的**：Apache-2.0 对工具输出没有任何主张和共留权 —— 它们不是流程的派生作品，就像 GCC 编译的二进制文件不是 GCC 的派生作品一样。
**AI 生成的 RTL。** 在流程步骤由 AI 编写（spec-to-RTL、预言测试基准）时，生成的代码由 **您，用户** 持有，作为您的作品。注意当前的美国立场：AI 不能被命名为 **发明者**（Thaler v. Vidal, Fed. Cir. 2022），但具有显著人类贡献的 AI 辅助输出是普通的、可拥有的 IP。生成的流程工件带有出处标头，准确说明这一点。
**制造责任。** 晶圆厂签收、制造资格认证和产品认证是用户的责任 — Vibe-IC 的签收关卡是开源等效和诚实的披露，而不是晶圆厂保证。
**商业工具防火墙。** 整个 1–44 流程仅在开源工具上运行；Vibe-IC 不会捆绑或要求任何商业 EDA。如果您用商业工具替换某个步骤（例如，在 OpenSTA 替换 PrimeTime），该工具的输出受其 **EULA** 管辖，由您负责，并且 **不得** 贡献回此仓库。开放 ↔ 商业替换通过 `programs/tool_substitution_disclose.py` 公开。
**贡献。** 进入的贡献遵循 Apache-2.0 §5，具有明确的 DCO + 专利不主张誓言 — 请参见 [CONTRIBUTING.md](CONTRIBUTING.md)。
---
## 致谢
Vibe-IC 建立在庞大的开源 EDA 社区之上。有关我们封装的第三方工具和实现的开放标准，请参见 [NOTICE](NOTICE)。
特别是：
- **OpenROAD**、**Yosys**、**KLayout**、**Magic**、**ngspice** 和 **cocotb** 项目，它们的数十年工作使得这种 AI 驱动的 IC 流程成为可能。
- **IIC OSIC Tools** 提供精选的 Docker 镜像。
- **FOSSi 基金会**、**libre-silicon** 和 **RISC-V 国际** 提供社区和标准。
- **Tiny Tapeout** 和 **eFabless Caravel** 证明了业余爱好者晶圆投片是真实的。
连接信息
猜你喜欢
暂无推荐服务器