Lumerical与OptoCompiler集成实践：打通光子芯片设计

做了这么多年光子芯片设计，我越来越觉得单点工具玩得再溜，也不如把流程打通来得痛快。今天想跟大家聊聊 Lumerical 和 OptoCompiler 集成这件事——一个偏物理级仿真，一个偏版图与流程管理，两者结合起来，才能真正支撑起高效的光子集成电路（PIC）设计与电光协同仿真流程。

这套玩法适合谁？如果你正在做硅光芯片、薄膜铌酸锂调制器、或者任何需要把无源器件、有源器件和外围电路放在一起联合仿真的项目，又受够了在 FDTD 和版图工具之间手动导来导去，那这篇文章就是给你准备的。我会直接讲清楚集成思路、核心操作、参数传递的关键细节，还有我实际踩过的坑。

1. 为什么要做 Lumerical 与 OptoCompiler 的集成

1.1 光子设计流程的现状与痛点

光子集成电路的设计流程，早年是真·手工作坊。版图工程师在 OptoCompiler 里画好 Layout，把 GDSII 导出来，然后扔给做仿真的同事，仿真工程师再在 Lumerical 里手动建模、画波导、设置材料、跑 FDTD 或者 MODE，算完 S 参数之后再反馈给版图那边，改一版，再导一次，再算一次。

这个流程听起来没毛病，但实际跑起来极其痛苦。首先是效率极低，一个稍微复杂一点的 MZI 链路或者微环阵列，手动在 Lumerical 里建模的时间往往比仿真本身还长。其次是容易出错，手动建模过程中，波导宽度、弯曲半径、耦合间距这些关键参数，一不小心就打错一位小数，仿真结果和实际版图对不上，最后流片回来测出来不一致，你根本不知道是仿真错了还是版图画错了。最要命的是，电光协同仿真基本靠猜，光路和电路分别在两套工具里跑，中间通过文件交换数据，稍微复杂一点的调制器设计，光域的动态响应和电路的瞬态行为根本没法统一起来分析。

所以当我第一次看到 Lumerical 和 OptoCompiler 的集成方案时，第一反应是：终于有人来解决这个割裂问题了。

1.2 两个工具各自的定位与优势

先捋清这两者的分工。Lumerical 是 Ansys 旗下的光子仿真套件，核心强项在物理级仿真。FDTD 做纳米光子结构的高保真仿真，MODE 做波导模式分析，INTERCONNECT 做系统级的光子链路仿真，还有用于电光协同的 device 求解器，比如 CHARGE 做载流子输运分析。这套工具的精度在业界是公认的，算出来的 S 参数、模式有效折射率、损耗系数这些，基本可以作为流片依据。

OptoCompiler 则是 Synopsys 的光子设计套件，核心强项在版图绘制、PDK 管理和设计流程管理。它把光子和电子的版图统一到一个环境下，支持参数化单元（PCell），内置了 PDK 的校验流程，还有和众多晶圆厂的流片接口。简单说，OptoCompiler 管的是"你画了什么，到底符不符合工艺规则，能不能送出去流片"这件事。

两者集成之后，版图里的参数化器件可以直接驱动 Lumerical 仿真，仿真结果又可以反向校准 PDK 模型，最终在 INTERCONNECT 里完成包含完整电路效应的电光协同仿真。听起来很理想，但具体怎么落地，下面展开聊。

2. 集成方案的核心思路与架构设计

2.1 基于 PDK 的集成模式

这次集成的关键，我觉得在于 PDK 这个中间层。很多人以为集成就是装个插件，其实不是，真正理顺的集成是围绕 PDK 来组织的。

具体是什么逻辑呢？在 OptoCompiler 里有 PDK，定义好了每个光子器件（比如弯曲波导、定向耦合器、微环调制器）的版图参数，比如宽度、半径、间距这些。这些器件在 Lumerical 里也有对应的仿真模型，但问题是，两边的参数怎么对应上、由谁来维护对应关系，这就是集成要解决的核心问题。

比较靠谱的做法是，在 PDK 层面为每个器件挂载一份"仿真配置"，这份配置里声明了器件的关键版图参数、仿真类型（FDTD 还是 MODE）、仿真波长范围、网格精度要求、以及输出结果的格式。OptoCompiler 通过一个互操作层读取这份配置，当你在版图上选中这个器件实例时，可以直接一键调用 Lumerical 做仿真，参数自动带上，不需要手动建模，也不需要复制粘贴数值。

这样做的好处很明显——仿真模型和版图模型共用同一套参数源，一致性天然保证。改版图参数时，仿真参数是跟着变的，不会再出现两边对不上的情况。而且 PDK 里还可以维护多套仿真模型，比如快速粗模和精确细模，在方案探索阶段用粗模跑得快，在最终验证阶段用细模保证精度，两者的切换在集成环境里可以做到一键完成。

2.2 数据交互的接口设计

再看数据层面。OptoCompiler 和 Lumerical 之间的数据交互，主要涉及三类信息：版图几何信息、器件参数、仿真结果。

版图几何信息这块，传统做法是走 GDSII 文件，格式通用但信息量太薄，只有图形没有参数和层语义。更好的交互方式是通过工艺文件映射，让 OptoCompiler 知道版图上每一层对应 Lumerical 材料库里的哪种材料，几何图形直接还原为仿真模型。这里面有个细节值得注意——GDSII 里的路径对象在 Lumerical 里需要重新网格化，不同工具的网格算法不一样，几何还原时容易产生微小偏差，集成层需要做容差处理，否则会引入莫名其妙的仿真误差。

器件参数和数据交换则通过结构化接口来完成。器件参数用 JSON 或 YAML 传递，每个器件实例的 ID、参数名、参数值、单位都写得很清楚，两边都能解析，就算中间环节出问题，人工排查也方便。仿真结果通过标准的 touchstone 文件（S 参数）或者 HDF5 格式（场分布、模式数据）回流，INTERCONNECT 拿到后可以直接在链路层做分析。关键点是接口设计要考虑批量场景——一个大型 PIC 里几百个器件实例，总不能一个个手动触发仿真，集成框架必须支持批量参数扫描和批量仿真任务提交。

2.3 集成架构的层次划分

从实现角度看，集成架构通常分成三层。第一层是几何映射层，负责把 OptoCompiler 里的版图对象转换为 Lumerical 的几何构件，材料映射、层映射、尺寸换算都在这一层完成。第二层是仿真控制层，负责触发仿真、传递参数、监控任务状态、回收结果，这一层相当于一个轻量级的任务调度器。第三层是数据回注层，把仿真结果反向写回 OptoCompiler 的 PDK 模型里，用于后续的 Design Rule Check 或者模型校准。

这三层划分开之后，整个集成的扩展性会好很多。你要接入新的器件类型，只需要在几何映射层添加映射规则，在仿真控制层注册仿真模板；你要更换仿真工具（比如部分器件要跑 FDTD，部分要跑 RCWA），只需要替换仿真控制层的具体实现。这种松耦合的架构，在实际项目中非常好用。

3. 实操过程与核心环节实现

3.1 环境准备与基础配置

实操之前，先把环境准备好。我用的是 OptoCompiler 2023.12-SP1 和 Lumerical 2023 R2.2，两个工具装在同一台 Linux 工作站上，操作系统是 CentOS 7.9。联网和 license 配置这些基础操作不展开，但要特别说一句：版本兼容性一定要提前确认好。这两个工具的集成插件对版本匹配比较敏感，旧版本 OptoCompiler 配新版本 Lumerical 有时会出现接口函数不兼容的问题，建议直接查官方兼容性矩阵再选版本。

安装完集成模块之后，第一件事是配置路径映射。在 OptoCompiler 的环境脚本里设置 Lumerical 的安装路径，同时确保两边共享同一个工作目录——我习惯把所有工程文件放在 /project/ 下，下面按项目名分目录，每个项目目录里再划分 layout/、sim/、results/ 三个子目录。这样做的原因很朴素，两边的相对路径一致，换机器、迁移项目时不会因为绝对路径对不上而报错。

环境验证有个快速方法，在 OptoCompiler 里随便建一个 MZI 的版图，选中其中一个弯曲波导，右键如果能看到 "Simulate with Lumerical" 这个选项，说明集成通道基本是通的。我第一次测试时就卡在这里，右键菜单怎么都不出现这个选项，后来发现是环境脚本没 source 对，改成 bash 启动后问题解决。

3.2 从版图到仿真模型的快速转换

集成的第一个高频操作，是把版图几何转换为 Lumerical 可用的仿真模型。这一步的要求是快和准，快是指操作流程短，准是指几何参数不能有偏差。

实际操作中，在 OptoCompiler 里完成版图设计后，先跑一遍 LVS（版图与原理图一致性检查），确认器件连接关系没问题。然后选中需要仿真的器件（比如定向耦合器），在集成面板里点击"Export to Lumerical"，系统弹出一个配置窗口，需要确认几个关键选项：仿真类型是 FDTD 还是 MODE，波长范围是多少（硅光通常 1.5~1.6μm），网格精度（默认用 auto，但涉及关键耦合间隙时建议手动设置，后面会说），以及材料模型是选色散模型还是常用折射率常数。

这里有一个非常需要注意的点：薄层材料的处理。硅光芯片通常有 BOX 层、Si 芯层、SiO2 上包层，有时候还有氮化硅附加层。Lumerical 的默认材料库里有硅和二氧化硅的 Palik 数据，但多层结构的层厚比和边界关系必须严格从版图工艺层映射过来，否则仿真结果会整体偏掉。我在实际项目里就遇到过——版图里的刻蚀深度标记为 70nm，但导出到 Lumerical 后发现几何模型里对应的蚀刻区域深度设成了 0，原因是工艺层映射表里没有配置 etch 层的深度属性。这个坑后来通过修改映射配置文件解决，但当时排查了很久才定位到原因。

几何转换后，建议先用 MODE 求解器做一个快速验证，看模式和有效折射率是否合理。有效折射率数值如果跟理论估算偏差超过 0.01，大概率是材料或几何映射出了问题，趁早排查，别等到 FDTD 跑完才发现。

3.3 仿真任务的下发与批量执行

单个器件仿真设置好之后，更实用的场景是批量仿真。我那个项目里有一个 8 通道微环阵列，每个微环的耦合间距各不相同，如果一个个手动仿真，每个环至少半小时起步，一整天就耗在等结果上。集成框架里的批量任务功能解决了这个问题。

操作方法是：在 OptoCompiler 里选中所有需要仿真的微环器件，在集成面板里选择"Batch Simulation"模式，系统会逐个器件生成仿真工程、设置参数、提交到任务队列。有一个配置需要注意：任务并发数。默认是 1，即逐个串行跑。如果你的计算节点核数够多（我常用 32 核），可以调到 4~6 并发，吞吐量会明显提升。但并发不是越高越好，FDTD 仿真对内存的要求很高，并发数乘单任务内存不能超过节点物理内存，否则会触发 swap，仿真速度反而急剧下降。

我在 32 核机器上做过实测对比：并发数从 1 提到 4，8 个仿真任务的总耗时从约 4 小时压缩到约 1.5 小时，效率提升明显。但继续提高到 6 时，由于内存带宽瓶颈，提升就不那么明显了，收益递减。这个经验仅供参考，具体数值取决于你的器件复杂度和机器配置。

批量任务跑完后，结果会自动分类存放在 results/ 目录下，每个器件一个子目录，文件名里带上器件实例 ID，方便回溯。千万别把结果文件名统一命名为 result.mat 之类的，几十个器件跑下来，没人分得清哪个是哪个，等到要定位问题时心态会炸。

3.4 电光协同仿真的联合流程搭建

接下来是最关键的电光协同仿真。光路部分和电路部分怎么在同一个仿真环境里协调运行，这才是集成方案的终极考验。

我的做法是在 INTERCONNECT 里搭光路链路，在 PrimeSIM 或 Circuit 求解器里跑电路瞬态仿真，两者通过电光接口模型进行数据交换。具体到这个项目里，我设计了一个 MZM（马赫-曾德尔调制器）的电光协同仿真流。大概流程分四步：

第一步，在 Lumerical 里完成调制器的光学仿真，用 CHARGE 求解器计算不同偏置电压下载流子浓度分布，然后把浓度分布导入 DEVICE 求解器，计算得到不同偏置下的有效折射率变化和损耗变化。这些数据整合成一个查找表，描述"电压-折射率变化-损耗"的对应关系。

第二步，在 OptoCompiler 里完成 MZM 的版图设计，包括行波电极的布局，然后把版图导出到 Lumerical 验证高频电极特性——这一步通常用 HFSS 来做，算电极的高频损耗和相速度。

第三步，把第一步得到的查找表和第二步的电极模型整合进 INTERCONNECT 的电光器件模型里，这个模型接受电输入信号，输出光域响应。

第四步，在 INTERCONNECT 里搭建完整测试链路：光输入接 MZM，射频源接调制器电端口，探测器接收输出光信号。同时配合电路求解器，加入驱动器等效电路和负载终端。跑完瞬态仿真后，直接看眼图和 BER。

这套流程的好处是整个链路都在同一个环境里调试，改一个参数（比如调制器偏置点），立即可以重跑瞬态仿真看到效果。如果是传统流程，你得先在 CHARGE 里跑一轮静态仿真——这通常要几十分钟——然后重新导入 INTERCONNECT，效率完全不是一个量级。

3.5 模型校准与 PDK 迭代更新

最后这一环是我个人觉得集成方案里最巧妙的部分——仿真结果反向校准 PDK 模型。

硅光 PDK 里的器件模型，通常是根据理论公式建立的简化模型。理想情况下，这些模型和实际工艺是吻合的，但工艺漂移、制造误差都会让实际器件偏离理论值。如果没有仿真校准，那你用来设计整条链路的模型可能从一开始就有偏差。

使用集成方案后，流程变成了这样：拿到流片回来的测试数据后，把实测 S 参数和仿真 S 参数做对比。如果存在系统性偏差（比如所有微环的谐振波长都偏了 2nm），说明 PDK 模型里的某个参数（比如波导宽度或有效折射率）需要修正。在集成环境里，你可以直接在 OptoCompiler 的器件属性里修改这个参数，重新导出到 Lumerical 仿真验证，确认修改后的结果和实测吻合后，将这个修正写回 PDK 模型库。

这个"测试-仿真-校准-更新模型"的闭环，是传统流程很难做到的。传统流程里，模型是 PDK 厂商给的，你只能接受，最多在自建模型里做个偏移量补偿，但补偿值是否合理无从验证。集成环境里，校准变成了一个标准操作流程，虽然每次校准仍然需要花时间跑仿真，但全流程打通后，你维护的 PDK 模型会越来越接近实际工艺，后面对着模型做设计，置信度会非常高。

4. 常见问题与排查技巧实录

4.1 几何映射偏差问题

我在项目中遇到最坑的问题之一是几何映射偏差。有一次批量仿真微环阵列，常规的耦合间距 200nm 设计值，仿真出来的耦合系数和理论预期偏差了将近 8%。查了很久，最后定位到是 Lumerical 在导入版图几何时，把波导边界做了平滑处理，导致耦合区域的间隙从 200nm 变成了 204nm——对于耦合系数这种对间距极度敏感的参数，4nm 的偏差就足以产生显著影响。

排查思路供参考：先对比导入前后的几何关键尺寸，Lumerical 里可以通过脚本读取模型几何信息和原版图做差值比对，非常高效。如果发现偏差，优先尝试调整导入设置里的几何重建精度，通常可以缓解。如果还是不行，建议在关键敏感区域（耦合间隙、刻蚀槽）做手动微调，用脚本控制确保最终几何和设计一致。

4.2 版本兼容性与 license 问题

集成环境里另一类常见问题是版本与 license。OptoCompiler 和 Lumerical 的版本兼容性没确认好，轻则某些功能失效，重则整个集成面板无法加载。建议在项目实施前就把版本兼容性表找出来，严格按推荐组合安装。还有 license 池的问题，两个工具都要占用 license，如果 license 数量有限，批量仿真时很容易因为 license 冲突导致任务排队太久。我的做法是单独给集成仿真分配一个 license 池，避免和版图设计的 license 竞争。

4.3 仿真中途报错与任务恢复

FDTD 仿真非常吃计算资源，跑了几个小时突然报错终止，这是家常便饭。集成的批量任务功能可以配置断点续算，但前提是提交任务时勾选了自动保存状态。有一个细节要留意：FDTD 的检查点文件通常比较大（几个 GB 级别），批量任务如果都开了自动保存，磁盘空间消耗非常大。我建议只在关键验证阶段开启断点续算，常规参数扫描阶段不要开，省下磁盘空间，真有任务断了就重新提交，一般影响不大。

仿真报错的排查也有套路可循。第一步先看日志，Lumerical 的日志分得很细，但绝大多数报错根因就三类：几何体互相穿透（通常是因为映射时坐标偏差）、材料参数缺失（通常是因为层映射没配好）、网格生成失败（通常是因为某个区域尺寸过小或曲率过大）。记住这个分类，排查效率会高很多。

4.4 参数传递中的单位与坐标系陷阱

最后一个坑，单位与坐标系。OptoCompiler 默认使用微米，Lumerical 也支持微米，但某些接口函数里默认单位是米，如果一个不留神，所有参数被放大了一千倍，完全离谱。我的建议是：在集成配置里显式声明单位制，并在两侧的模型文件里都写上单位注释，哪怕看起来多此一举，也比排查单位导致的神秘误差省时间。坐标系方面，特别留意 GDSII 坐标原点位置。版图设计时习惯把原点设在芯片中心，而 Lumerical 建模时习惯从原点开始画，两边对接很容易产生整体偏移。解决方法是固定使用同一个参考原点，并定期用校准结构（简单的直波导）做导数验证。

4.5 常见问题速查表

5. 实操心得与优化建议

5.1 流程优化经验

用这套集成流程做项目，我最大的体会是：真正的效率提升不在于单个仿真跑得多快，而在于整个迭代链路有多顺。以前改一版设计，版图改完到仿真结果出来，中间至少一两天；现在基本控制在半天以内。如果你要追求更快的迭代速度，有两点建议。

第一，合理分级使用仿真工具。不同设计阶段用不同精度的仿真，方案探索阶段多用 MODE 求解器和解析模型，只有关键性能验证才跑 FDTD。很多人在方案早期就上 FDTD，一个结构仿真几小时，一天跑不了几个方案，实际上完全没必要。

第二，把重复性操作沉淀为自动化脚本。集成框架本身提供 Python API，可以把"导入版图-设置仿真-提交任务-收集结果"这整个流程脚本化。同一类器件、同一类扫描参数，脚本可以直接复用。我自己把微环、MZM、AWG 这几个常用器件的仿真流都写成了脚本模板，新项目拿来改几个参数就能用，省掉了大量的重复操作时间。

5.2 扩展方向

最后说一句，这个集成方案的扩展空间其实很大。眼下主要是 Lumerical 和 OptoCompiler 两家打通，但在实际工程里，前端有系统级架构仿真，后端有封装和测试环节，中间还有热分析、应力分析这些多物理场需求。如果你已经跑通了光电协同仿真，下一步可以尝试往多物理场方向延伸——比如把电热效应引入调制器仿真，或者把应力双折射影响引入波导器件分析。这些在集成框架下都是可以逐步扩展的。

我的建议是不要贪多，先把光电协同这条主链路彻底用顺，再逐步扩展。我自己就是在微环调制器项目上跑通了全流程之后，才把同样套路复制到其他器件的。这个集成流程，确实是目前做光子 IC 设计绕不开的硬核技能。