做了这么多年光子芯片设计我越来越觉得单点工具玩得再溜也不如把流程打通来得痛快。今天想跟大家聊聊 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 提到 48 个仿真任务的总耗时从约 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 常见问题速查表问题现象可能原因排查方法右键菜单无集成选项环境脚本未加载 / 版本不兼容检查环境变量和插件版本几何尺寸偏差导入容差设置过大调整几何重建精度或手动修正材料折射率不对工艺层映射表配置错误检查映射文件中的层与材料对应关系批量任务排队过久license 池冲突 / 并发数过高单独分配 license、调整并发数仿真结果突然全部偏移单位制设置不一致显式声明单位并核对两处设置结果文件分不清文件命名规则不清晰按器件实例 ID 命名归档至独立目录5. 实操心得与优化建议5.1 流程优化经验用这套集成流程做项目我最大的体会是真正的效率提升不在于单个仿真跑得多快而在于整个迭代链路有多顺。以前改一版设计版图改完到仿真结果出来中间至少一两天现在基本控制在半天以内。如果你要追求更快的迭代速度有两点建议。第一合理分级使用仿真工具。不同设计阶段用不同精度的仿真方案探索阶段多用 MODE 求解器和解析模型只有关键性能验证才跑 FDTD。很多人在方案早期就上 FDTD一个结构仿真几小时一天跑不了几个方案实际上完全没必要。第二把重复性操作沉淀为自动化脚本。集成框架本身提供 Python API可以把导入版图-设置仿真-提交任务-收集结果这整个流程脚本化。同一类器件、同一类扫描参数脚本可以直接复用。我自己把微环、MZM、AWG 这几个常用器件的仿真流都写成了脚本模板新项目拿来改几个参数就能用省掉了大量的重复操作时间。5.2 扩展方向最后说一句这个集成方案的扩展空间其实很大。眼下主要是 Lumerical 和 OptoCompiler 两家打通但在实际工程里前端有系统级架构仿真后端有封装和测试环节中间还有热分析、应力分析这些多物理场需求。如果你已经跑通了光电协同仿真下一步可以尝试往多物理场方向延伸——比如把电热效应引入调制器仿真或者把应力双折射影响引入波导器件分析。这些在集成框架下都是可以逐步扩展的。我的建议是不要贪多先把光电协同这条主链路彻底用顺再逐步扩展。我自己就是在微环调制器项目上跑通了全流程之后才把同样套路复制到其他器件的。这个集成流程确实是目前做光子 IC 设计绕不开的硬核技能。
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 提到 48 个仿真任务的总耗时从约 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 常见问题速查表问题现象可能原因排查方法右键菜单无集成选项环境脚本未加载 / 版本不兼容检查环境变量和插件版本几何尺寸偏差导入容差设置过大调整几何重建精度或手动修正材料折射率不对工艺层映射表配置错误检查映射文件中的层与材料对应关系批量任务排队过久license 池冲突 / 并发数过高单独分配 license、调整并发数仿真结果突然全部偏移单位制设置不一致显式声明单位并核对两处设置结果文件分不清文件命名规则不清晰按器件实例 ID 命名归档至独立目录5. 实操心得与优化建议5.1 流程优化经验用这套集成流程做项目我最大的体会是真正的效率提升不在于单个仿真跑得多快而在于整个迭代链路有多顺。以前改一版设计版图改完到仿真结果出来中间至少一两天现在基本控制在半天以内。如果你要追求更快的迭代速度有两点建议。第一合理分级使用仿真工具。不同设计阶段用不同精度的仿真方案探索阶段多用 MODE 求解器和解析模型只有关键性能验证才跑 FDTD。很多人在方案早期就上 FDTD一个结构仿真几小时一天跑不了几个方案实际上完全没必要。第二把重复性操作沉淀为自动化脚本。集成框架本身提供 Python API可以把导入版图-设置仿真-提交任务-收集结果这整个流程脚本化。同一类器件、同一类扫描参数脚本可以直接复用。我自己把微环、MZM、AWG 这几个常用器件的仿真流都写成了脚本模板新项目拿来改几个参数就能用省掉了大量的重复操作时间。5.2 扩展方向最后说一句这个集成方案的扩展空间其实很大。眼下主要是 Lumerical 和 OptoCompiler 两家打通但在实际工程里前端有系统级架构仿真后端有封装和测试环节中间还有热分析、应力分析这些多物理场需求。如果你已经跑通了光电协同仿真下一步可以尝试往多物理场方向延伸——比如把电热效应引入调制器仿真或者把应力双折射影响引入波导器件分析。这些在集成框架下都是可以逐步扩展的。我的建议是不要贪多先把光电协同这条主链路彻底用顺再逐步扩展。我自己就是在微环调制器项目上跑通了全流程之后才把同样套路复制到其他器件的。这个集成流程确实是目前做光子 IC 设计绕不开的硬核技能。
工具上手)
