2. 团队架构与分工：PDK、版图、测试、系统各角色如何协作？
说实话，硅光芯片设计和传统电子芯片设计最大的不同，就是它太「跨界」了。
你想想看，一个项目里既有搞光学仿真的，又有画版图的，还有搭测试平台的。这些人平时说话用的术语都不一样，怎么让他们高效协作？
我这些年踩过的坑，有一半都是因为角色之间信息没对齐。今天咱们就聊聊，PDK、版图、测试、系统这几个角色，到底该怎么分工，怎么配合。
2.1 角色定义：谁该干什么？
先给每个角色画个像。别小看这一步，很多团队乱就乱在职责边界模糊。
| 角色 | 核心职责 | 交付物 |
|---|---|---|
| PDK 工程师 | 建立工艺设计套件，提供器件模型、设计规则、仿真模型 | PDK 库文件、设计规则手册、仿真模型 |
| 版图工程师 | 根据电路设计，完成物理版图绘制与DRC/LVS验证 | GDSII 版图文件、验证报告 |
| 测试工程师 | 制定测试方案，搭建测试平台，完成芯片性能表征 | 测试计划、测试数据、失效分析报告 |
| 系统工程师 | 定义系统架构，分解指标，协调各模块需求 | 系统规格书、接口定义文档 |
2.2 协作流程：信息流怎么走？
光有分工还不够，关键是信息怎么流动。我见过最糟糕的情况是：版图改了一根波导的宽度，没人通知测试，结果测试那边按旧参数搭好了平台，全白干。
下面这张图是我个人比较推崇的协作流程，你可以参考一下：
核心原则：测试工程师一定要「左移」。别等到版图都画完了才叫测试来看。我建议在系统定义阶段，测试就要参与进来，确认可测性。
2.3 常见协作痛点与避坑指南
说几个我亲身经历过的坑，你对照一下自己的团队，看看有没有类似问题。
痛点一：PDK 模型不准，版图白画
有一次，PDK 给的 MZI 分束器模型，仿真出来插损 0.5 dB。版图照着画了，结果流片回来一测，实际插损 1.2 dB。整个链路预算全崩了。
痛点二：版图改了，测试不知道
版图工程师为了通过 DRC，悄悄把某个波导的间距从 2 μm 改成了 1.8 μm。没人通知测试。结果测试时发现耦合效率不对，查了两天才找到原因。
痛点三：系统指标太理想，工艺实现不了
系统工程师拍脑袋定了 100 GHz 的调制带宽。PDK 一看，说这个工艺的电极 RC 延迟根本做不到。两边吵了一个星期。
说白了，系统工程师需要懂一点工艺限制。我建议系统工程师至少花一周时间，跟 PDK 工程师一起跑一遍关键器件的工艺角仿真。这样定指标时心里有数。
2.4 协作工具与文档规范
工具选对了，协作效率能翻倍。我推荐几个组合：
- 版本管理：Git + Git LFS。版图文件大，用 LFS 管理。所有文档、脚本、模型都进 Git。
- 需求追踪：Jira 或飞书多维表格。每个需求关联具体负责人和截止时间。
- 接口文档：用 Markdown 写，放在 Git 仓库里。每次修改都要走 PR 流程。
一个血的教训：我见过一个团队，测试和版图用两个不同版本的 Excel 记录端口定义。结果对不上，浪费了两周时间。后来我强制要求：所有接口定义必须写在同一个 Markdown 文件里，以 Git 仓库里的版本为准。
2.5 总结：协作的本质是「信任」
说了这么多，其实就一句话：每个角色都要对其他角色的工作有基本的信任，同时也要提供足够的信息让对方信任你。
PDK 工程师要相信版图会遵守设计规则，版图要相信测试能发现隐藏的问题，测试要相信系统给的指标是合理的。这种信任不是靠人情，而是靠规范的流程和透明的信息。
嗯，做到这些，你的团队至少能少踩一半的坑。