做硅光芯片设计这几年我的体会一直都是单点工具从来不缺缺的是把物理仿真、电路仿真和版图设计串起来的那根线。Lumerical和OptoCompiler放在一起恰好就是为解决这件事来的——前者负责把光子器件的电磁特性和半导体物理效应算到足够准后者负责把器件放到电路里、落到版图上、跑通链路级和电光协同仿真。这篇内容我会从实际项目视角出发聊一聊两者集成后的工作流怎么搭、PDK怎么建、MZM这种典型电光链路怎么跑协同仿真最后把我在反复实操中踩过的坑整理成清单。不管你是刚接触光子集成电路设计的学生还是已经在用OptoCompiler画版图的工程师这篇东西应该都能帮你绕开几条弯路。1. 单点工具不缺链条断开才是光子集成开发的真痛点1.1 没有集成时我们是怎么折腾的早先做PIC项目时最常见的路径是先用FDTD把无源器件算了得到透过率、插损、相位再用CHARGE或者Device这类工具把调制器的电学行为算了得到载流子浓度变化导出数据之后再手动把这些结果填到链路仿真工具里手工调一段网表最后再去画版图。听起来每一步都有工具在做但问题是步骤和步骤之间全靠人肉搬运。只要版图改过一次几何尺寸前面所有仿真结果里对应的那个元件模型就得跟着重来一遍。有一次我改了一个MMI的长宽仿真数据已更新但链路模型文件忘了同步结果系统级仿真跑出来插损异常排查了两天才发现是模型和版图对不上。这种问题在工具链路没有打通的项目组里几乎每隔几周就出现一次。真正制约光子集成电路设计效率的不是某个求解器不够快而是器件级结果和电路级模型之间的断链。1.2 Lumerical和OptoCompiler分别解决哪一层Lumerical家族擅长的是物理级仿真。FDTD Solutions做无源器件MODE Solutions做波导模式分析CHARGE做半导体电学载流子输运INTERCONNECT做光子链路级频域和时域仿真。它解决的问题是某个具体结构在给定波长、偏振、电压、温度下光学行为到底是什么。OptoCompiler解决的是系统设计和工程化问题原理图怎么组织、器件该怎么摆进版图、PDK该怎么管理、DRC/LVS怎么做、最终怎么和电学仿真器协同。你可以把它理解为设计师的工作台所有器件以单元形式挂进来用网表描述连接关系版图由PCell自动生成最后还能把光域结果和电域结果合并看眼图。两者集成真正解决的核心问题就是把“这个器件物理上性能如何”和“这颗芯片系统上表现如何”这两层内容用一套自动化的数据流串起来。没有了这层数据流你得到的只会是一堆孤岛式仿真报告。2. 集成链路的数据流从物理场到电路网表信息一层层被“抽象”2.1 光学器件是怎么被抽象成模型的任何仿真流程的本质都是做抽象。FDTD这种场级工具里面看的是电场分布、磁场分布网格小到纳米级仿真结果是连续的三维数据体。但到了电路级仿真我们不可能让SPICE或光子链路仿真器去解三维麦克斯韦方程必须把器件行为压缩成端口网络模型。Lumerical里通常的做法是对一个器件跑完场级仿真之后提取它的散射矩阵。常见输出是S参数文件比如touchstone格式再配合群延迟、相位响应、模式变换这些参数。对调制器这类有源器件还要加上电学端口的RC寄生参数以及电压引起的折射率变化曲线。这些东西打包在一起就构成了电路仿真器能识别的一个紧凑模型。从场级数据到紧凑模型的过程就是这个抽象过程中最需要小心的一步。因为S参数是频域的到了INTERCONNECT或者OptoCompiler的时域仿真里还需要做频时变换。如果频带取的太窄或者频点不够密时域结果就会出现拖尾和非物理振荡。所以我一直强调集成流程不只是把文件导出来再导进去背后有一整套关于频带、插值、参考面的约定这些细节直接决定协同仿真的准确性。2.2 电学世界的接入SPICE、Verilog-A与光网络的对话电光协同仿真最难的地方在于光路是连续波导电路是带电阻电容和晶体管的电网络时间尺度还经常差着数量级。在OptoCompiler这套环境里光路部分通过光端口连接每个端口携带模式信息、波长和功率电路部分则走标准电学网表兼容SPICE一类工具。建模的时候无源光器件一般表现为光域的多端口S参数电光调制器则是一个四端口以上的混合器件光输入、光输出、电正极、电负极。仿真器需要同时解“光沿着波导传了多少”和“电信号如何在电极上传播”这两件事。我见过比较稳妥的做法是分层处理光域用Lumerical的紧凑模型电域用SPICE模型两者在器件层面通过“由电信号改变光学参数”的关系耦合。这层耦合关系通常写成查找表或者Verilog-A等效电路仿真时在每个时间步读取电压再去查对应的光学响应。整个过程听起来复杂但正是因为OptoCompiler把光网络和电网络统一到了一个仿真环境里我们才能把这两套物理域放到同一把时域下游标下评估。2.3 协同仿真的两种模式怎么选实际项目里电光协同仿真通常有两个方向。一种是光路主导的链路仿真。光发射端、波导链路、无源器件、接收端全部用光学模型电驱动器用理想源或者简化电阻负载。这种模式跑得快适合早期架构评估比如链路预算、功耗估算、接收端灵敏度分析。另一种是电路主导的联合仿真。把电驱动器、TIA、跨阻放大器这些用真实PDK的SPICE模型搭起来光路部分继续保留光学器件模型两边同时仿真。这种模式精度高但耗时成倍上涨适合芯片已经进入实现阶段需要验证驱动器和调制器之间阻抗匹配、带宽、反射这些实际问题。两种模式不是替代关系而是前后关系。我的一般流程是先跑光路主导版本把链路预算定下来再逐步把电域模型换成真实电路模型做精细化验证最后输出给后仿。3. 把Lumerical结果变成OptoCompiler能用的PDK这一步决定了后续仿真质量3.1 一个光PDK应该包含哪些层级刚开始用OptoCompiler时我犯过一个很自然的错误把PDK理解成光器件的仿真模型集合。结果做下来才发现一套可用的光PDK至少要包含四个层面。第一层是器件原理图符号工程师画链路图时看到的东西。第二层是紧凑模型包括光学S参数、电学寄生参数、调制响应数据这是仿真时真正计算的依据。第三层是版图PCell也就是从原理图参数化生成GDS布局的代码。第四层是验证规则包括层映射、DRC间距规则、LVS连接识别规则。四个层面缺一个流程就会在某个环节卡住。比如有模型没PCell那仿真能跑但版图画不了有PCell没模型那版图画得出来但没法验证性能。我建议在集成初期就把这四层结构定清楚不要等所有器件都做完再补否则后面图中口径不统一返工量非常大。3.2 层映射、命名规则和符号库里的沙尘暴不是技术上的高深问题但命名和层映射真的能消耗掉项目组大量时间。光PDK里常见的坑是Lumerical INTERCONNECT中的端口名、OptoCompiler里的原理图引脚名、GDS上的几何层名三套体系经常对不上。有时候是大小写不一致光端口叫mod_in电引脚叫Mod_In导进去直接断开有时候是波导层号不同仿真层用21版图层用121DRC不认。这些错误在原理图仿真阶段根本不报直到LVS才突然爆发。我的办法是在PDK开发第一天就定一张层映射表把所有工具的命名对应关系列清楚然后写一个脚本去自动检查一致性。比如下面这个示意脚本每次更新PDK后跑一遍#!/bin/bash # 检查光端口命名一致性 grep MOD_IN optical_pdk.mapping | while read line; do port_name$(echo $line | awk {print $1}) sim_name$(echo $line | awk {print $2}) if [ $port_name ! $sim_name ]; then echo [ERROR] 端口命名不一致: $port_name vs $sim_name fi done这不算漂亮但它确实救过我很多次。命名规则这种东西人眼检查十次都不如脚本检查一次靠谱。3.3 从Lumerical导出S参数并生成模型文件的实际操作器件级仿真完成后导出模型这一步需要把关键信息全部带上否则后面链路线仿会缺参。我常用的流程是在FDTD里跑完指定波长范围然后在结果中提取端口S参数导出为touchstone格式。接着到INTERCONNECT的模型中把S参数文件导入进光网络元件同时把电学端口的RC参数填进对应的电学属性里。整个过程用Lumerical的脚本语言可以自动化大致逻辑是下面这样# Lumerical脚本示意提取MZM的S参数并生成紧凑模型 select(MZM_OPTICAL); set(port, 1); set(frequency range, 193.1e12, 193.7e12); set(number of points, 2001); runsweep(); export(mzm_s4p.touchstone, S); select(MZM_ELECTRICAL); set(resistance, 45); set(capacitance, 0.12e-12); export(mzm_electrical.json, model);导出后要做的一件事是检查频带宽度。我之前有次就是导出时图省事只选了200GHz带宽结果做25GBaud的PAM4仿真时时域波形明显畸变。原因是S参数没有覆盖到足够的高频分量时域变换之后高频信息恢复不出来。建议至少按信号波特率的5到8倍带宽来取频点。3.4 最小可用闭环先打通再扩充我特别提倡先做一个最简单的“最小PDK”而不是一上来就把几十个器件全部入库。比如先做一条波导、一个Y分支、一个调制器把从原理图仿真到版图生成的全流程走通。走通这个闭环能验证三件事原理图和版图是否同步模型的参数能不能正确落实到版图PCellDRC和LVS能不能不报错地认下这组单元。只要这个最小闭环通了后面的器件扩充只是在重复同一套流程风险小很多。4. 一条MZM链路的电光协同仿真完整流程拆给你看4.1 先把电域搭起来驱动器、电极与阻抗匹配MZM链路是电光协同仿真最经典的案例。我先从电域开始搭。驱动器的SPICE模型按项目实际电路来高速信号源接在驱动器输入端驱动器输出经过一小段传输线接到MZM的射频电极。电极模型在集成流程里常被简化成一条有损传输线再并联一个RC并联网络。这里最容易忽视的是阻抗匹配硅光调制器的TWE电极一般设计在接近50欧姆附近驱动器输出阻抗也是50欧姆两边的共轭匹配如果没对齐反射会体现在最终的光眼图上。我会在仿真里特意加一个电探针去看MZM电极上的实际电压波形而不是只看驱动器输出端的激励信号。很多时候驱动器输出信号是好的但过了传输线和电极之后已经变形了光信号自然不会好。4.2 光域建模调制器、波导、探测器怎么挂电域搭好之后光域部分在OptoCompiler里挂器件。光源用连续波激光器模型通过波导连到MZM的光输入端口。MZM的光学部分就是前面从Lumerical导出的S参数模型它里面包含了分光、相位、损耗和调制电压对透过率的响应关系。MZM输出连一段延迟波导再接探测器。探测器的模型这时候要特别留意它既有光端口又有电端口。光端口接收功率内部通过响应度把光功率转换为光生电流再送到后级TIA。很多新手在这里会直接把光信号接成电信号导致仿真器报错。正确做法是让探测器模型完成功率到电流的转换之后才进入电学仿真域。4.3 激励设置PRBS、眼图与时序对齐仿真激励我一般用PRBS7或者PRBS9速率按项目目标来比如56GBaud PAM4。此时要设置好信号源速率和仿真总时长总时长至少要覆盖几个完整的码元周期才能让眼图充分闭合。时域仿真里的步长设置是关键。步长太大会丢失高频细节步长太小则仿真时间爆炸。我的经验是先跑一个短时长的粗步长快速检查确认链路能通再加密步长跑正式结果。光学部分的数据点数也需要和高频信号匹配否则光信号的上升沿会被模型插值磨平。这里有一个很容易忽略的点光路和电路之间经常存在时延差特别是当链路里包含长波导时光信号会比电信号晚到几十甚至上百皮秒。在眼图分析时如果不先把接收端的电信号做时间对齐测出来的眼图看起来就是一团糊的。4.4 结果验证光眼图和电眼图一起看协同仿真的输出不要只看电眼图一定要结合光眼图一起分析。光电协同链路里光眼图反映的是调制器本身和光路部分的状态电眼图则反映的是探测和接收电路的状态。有一次我遇到链路整体消光比偏低的情况单独看电眼图完全正常但光眼图的“1”电平明显下塌。最后定位是MZM模型的偏置电压点设置不对静态工作点接近了传输曲线非线性的区域。如果当时只看电域结果这个问题根本不会暴露。所以我在流程里固定要求每次协同仿真必须同时抓取光口和电口的眼图、功率计读数、电压波形的频谱这样出了问题才能快速判断故障是在调制侧还是接收侧。5. 事后复盘我在这套流程里反复踩坑的地方5.1 S参数频带宽度不够时域结果拖尾这是我在协同仿真里遇到频率最高的问题。现象是光眼图的上升沿和下降沿后面跟着一个长长的“尾巴”看起来像振铃。排除掉电路反射之后问题锁定在S参数文件上。因为导出时频带只覆盖到信号速率的3倍左右时域变换后高频信息缺失系统响应自然就多出来一段虚的拖尾。解决方法是把S参数频率范围扩展到信号波特率的5到8倍同时增加频点密度。需要注意的另一方面是频带扩展后仿真步长也要跟着变细不然扩展了也没意义照样会因为时间采样不足而出现混叠。5.2 端口参考面不一致相位偏差很隐蔽不同器件导出S参数时参考面通常取在器件边界。但到了OptoCompiler链路里两个器件连接时会把端口直接拼在一起如果中间还有一段波导没有建模相位延迟就会缺了一截。这个坑在无源器件级联时尤其隐蔽因为幅度响应看不出问题只有相位叠加之后才能发现端口对不上。我现在习惯是每个器件在导出之前都检查一下端口的参考面定义并在链路里保留明确的波导连接段宁可多花一点仿真时间也不让参考面偷偷“吃”掉一段波导。5.3 PDK版本和仿真器版本混乱玄学报错集成环境里的版本问题相当折磨人。OptoCompiler、Lumerical、PDK库、甚至操作系统账号环境下装的Python库都可能互相影响。我遇到过一种情况同一个PDK在V21版本下能跑在V23版本下就报“missing property”但原理图和模型文件完全没动过。后来排查才发现不同版本对模型文件里某个默认值的解析逻辑变了老版本自动补全新版本直接报错。因为这个问题我现在对所有PDK都固定版本并且建立了一个环境的版本快照文件。升级工具之前先在一个独立目录里完整跑一遍回归测试确认所有模型和Rule文件都兼容再切换。5.4 大批量参数扫描时的资源占用电光协同仿真一旦涉及参数扫描资源消耗会非常夸张。比如想扫MZM调制器在不同偏压下对眼图的影响每个偏压点都是一次完整时域仿真单纯用循环去跑可能一星期都不够。我的做法是把参数扫描拆成两段。先把不依赖电信号的参数比如偏压点、无源损耗用链路仿真短时间粗扫找到可疑区间再对可疑的少数几个点做完整电光协同仿真。另外还可以尽量利用工具本身的多核并行能力把不同偏压点分配给不同核并行跑而不是在同一个任务的循环里串行等待。下表是我自己整理出来的常见问题和对应排查方向碰到类似情况可以参考一下现象根因方向优先检查项眼图高频拖尾S参数频率范围不足频率上限、频点密度两器件级联后相位异常端口参考面不一致器件边界到连接端口的波导长度原理图仿真正常LVS报错层映射或命名不一致层映射表和符号库命名相同网表在不同版本结果不同工具版本或PDK版本漂移版本快照、回归脚本长链路仿真时内存爆炸数据点过多且无压缩步长选择、结果采样策略6. 目前我比较认可的工作模式6.1 把脚本化检查嵌入流程集成流程跑通之后我最想强调的一点是要把所有检查项做成脚本而不是靠人工盯。我个人习惯的做法是建立三个自动检查点。第一是模型导出时对S参数带宽和频点密度的自动校验不合规直接中断第二是PDK更新后的端口命名和层映射一致性检查第三是每次长仿真前对网表做一次短路和悬空端口扫描。这样做之后我最明显的感觉是很多低级错误的定位时间从小时级降到了分钟级。6.2 器件级和电路级仿真的分工边界还有一个很重要的认知不是所有东西都值得放进同一个仿真里跑。器件级仿真里FDTD、CHARGE这种工具的职责是把单个器件的物理特性摸清楚。这一步不应该和电路仿真混在一起因为时间和网格尺度差距太大。到了电路级和系统级仿真大量用到的应该是已经验证过的紧凑模型。紧凑模型的可靠性来自器件级仿真阶段的充分验证。把这两个阶段清楚切开反而是提高整体研发效率的最好方式。有些人一上来就希望搭一个完全万能的模型让器件级和电路级在一个环境里同时仿真但这样做往往导致精度高的跑不动跑得动的又不够准。真正高效的流程是物理级的归物理级系统级的归系统级中间靠模型传递。6.3 扩展工艺角、统计仿真与后仿的真正价值当Lumerical和OptoCompiler的集成链路稳定之后再把工艺角、统计偏差这些因子放进来就能做更有工程价值的验证。比如对MZM来说工艺偏差会影响波导宽度进而影响有效折射率和调制效率。在OptoCompiler里只要在模型参数上加入工艺角变量就能通过参数扫描考察整个链路在工艺波动下的良率趋势。这种分析在流片前意义很大能提前帮助你判断设计余量是否充足。后仿的作用同样重要。版图寄生提取之后把寄生的RC参数反标回协同仿真模型跑出来的眼图和流片后测试的吻合度会明显提升。做到这一步整个从Lumerical到OptoCompiler的流程才算真正闭环模型和版图不再是两套互不相干的数据。按照我个人经验这套集成流程前期搭建时确实比传统人肉搬运流程要花更多准备工作但一旦跑通后续每个项目迭代节省下来的时间都是成倍数的。建议刚接触这套环境的团队不必追求一次把所有器件都做进PDK拿一条MZM链路作为切入点把整个数据流跑顺畅再用相同的方法去扩充其他器件。有了这个底座光子集成电路设计和电光协同仿真才谈得上真正的高效。