这几年做硅光收发链路设计我越来越确认一件事真正卡住项目进度的往往不是激光器功率不够也不是调制器带宽不够而是光芯片团队和电芯片团队各画各的等两边版图都出了才发现光口和电口的寄生参数、偏置条件、带宽裕量根本对不上。我最早干这活的场景很朴素——拿着Luceda里设计好的硅光PDK链路再切到Cadence Virtuoso里去画TIA和驱动电路两个工具之间靠手工截图和Excel表格传参数。一套PAM4的收发链路光域仿真和电域仿真各跑各的最后拼到一起总差一截信号完整性。后来我们尝试把Luceda和Cadence在流程上真正串起来做光电协同设计集成情况才明显好转。这篇内容不聊PPT架构只讲打通这套协同流程时实打实会碰到的机制、操作和坑。1. 光电“各画各的”时代我们到底吃了多少亏1.1 光芯片设计与电芯片设计的真实“温差”光芯片设计圈子里的主力工具这几年基本绕不开Luceda Photonics的IPKISS框架。它用Python把光链路搭成可编程的电路模型底层挂的是foundry提供的硅光PDK包含波导、MMI分束器、MZM调制器、Ge光电探测器这些光学元件最终能生成GDS版图也能跑S参数和时域光学仿真。这套工具链对光波导和版图约束的表述很清晰但它的强项不在这边——它对电学寄生、ESD保护、驱动器的输出阻抗这些事要么交给等效模型要么干脆不管。Cadence Virtuoso则是模拟/混合信号电路设计的老牌根据地。TIA、限幅放大器、MZM驱动器、LDD、SerDes收发前端都是在这里用PDK器件搭出来的。Virtuoso的优势在于SPICE级仿真足够精细能看PAM4眼图、能跑蒙特卡罗、能做版图寄生抽取后的后仿真。但问题也在这它的世界里没有“光”只有电压和电流顶多用行为级电流源或者光电流源去近似光电探测器的输出。两套工具一个管光、一个管电单独用都很强放到一起就成了断头路。光链路仿真给不出清晰的电学端口时序电链路仿真又不知道光学链路的实际插损、串扰和带宽于是两边设计人员只能靠口头对齐需求和猜。等GDS流片回来封装耦合完测试出来的误码率比仿真预估高一个量级才发现问题出在光电接口处的阻抗不匹配和带宽裕量不足。1.2 协同设计到底解决的是哪几类矛盾把Luceda和Cadence串起来本质上解决三类矛盾第一类是参数传递矛盾。光链路里调制器的半波电压Vpi、插入损耗IL、消光比ER直接决定电驱动电路的摆幅和功率预算探测器的响应度、暗电流、结电容直接决定TIA的增益和带宽设计。过去这些参数靠手工查表协同设计之后由同一套PDK数据模型统一管理S参数、等效电路和设计文档同源不会再出现光团队更新了器件版本电团队还在用旧参数画版图的情况。第二类是仿真域割裂矛盾。光链路里的时域波形比如MZM输出的PAM4光信号要用光学模型算但信号经过探测器之后进入TIA再到CDR的这一段又完全是电路仿真的事。协同集成之后可以把Luceda的光学行为模型嵌到Cadence Spectre的仿真网表里或者把电学仿真输出的驱动电压波形喂回Luceda的光学时域仿真形成闭合的“电-光-电”联合仿真环。第三类是版图一致性问题。硅光芯片的GDS里往往同时包含光波导版图和金属走线、焊盘、ESD结构这些电极结构必须和Cadence里封装的电芯片版图在尺寸、间距和压焊方案上对齐。协同设计流程里Luceda导出的光芯片版图可以带坐标信息回流到Cadence后端用来做封装基板或者芯片对准检查避免流片后才发现电极位置错半格这种低级错误。2. Luceda和Cadence在光电协同里各管哪一段2.1 Luceda IPKISS光域的中心化EDA平台IPKISS给我的感觉不是传统意义上点鼠标的工具它更像一个面向光子集成设计的Python框架。你用代码描述光链路拓扑先把foundry PDK里的元件实例化再把元件的端口通过波导连线然后跑光学仿真或者直接生成版图。这意味着光链路的每一个元件、每一段波导、每一个参数在项目里都是“可追溯的对象”不是在图形界面里画完就丢的孤岛。在光电协同集成场景里IPKISS最有用的能力有两块一块是光链路模型导出。IPKISS里有专门的模型生成模块能把复杂的光学链路编译成可以在外部EDA工具里调用的等效电学模型。常见的形式包括S参数Touchstone文件、Verilog-A行为模型、或者基于多项式近似的SPICE子电路。MZM可以被描述成一个电压控制的光学传输函数Ge探测器可以被描述成一个带结电容和串联电阻的光电流源。这些模型放到Cadence里就能让电路仿真器“看见”光学行为。另一块是版图数据带电气属性的导出。IPKISS生成的GDSII文件不只有多边形还可以带端口名、注释和层映射信息。你要是做过多芯片协同就会知道这些“看不见的信息”有多重要——后端工程师拿到光芯片的GDS之后能直接识别出哪个pad是射频信号输入、哪个pad是直流偏置、哪个区域禁止走线而不需要反复发邮件问光芯片工程师。2.2 Cadence Virtuoso电域的模拟/混合信号主战场Cadence这边负责的自然是电芯片设计。Virtuoso的架构大家熟原理图编辑、Spectre仿真、版图编辑、寄生参数抽取、物理验证各环节都有成熟的工具链。在光电协同流程里它承担的职责不只是“把电芯片画出来”更关键的是提供可信的电路级仿真环境和设计规则校验。具体来说Virtuoso在协同设计里有三个角色第一个是电学仿真宿主。Spectre仿真器可以挂载外部模型无论是厂商PDK的BSIM模型还是我们自己写的Verilog-A行为模型都能在统一网表里共存。Luceda导出的光电器件等效模型在Cadence里被当作普通的analogLib元件或者自定义pcell使用参与直流、瞬态、交流和谐波平衡仿真。第二个是数模混合验证平台。现代光模块的电芯片里不只有模拟前端还有数字控制逻辑、寄存器配置、DSP均衡器。Cadence的混合信号仿真平台比如XceliumVirtuoso ADE的协同允许数字RTL和模拟电路一起联合跑放在光链路场景里就能验证“数字AGC环路遇到光功率突变时TIA增益调整是否会导致光眼图塌陷”这类系统级问题。第三个是版图和封装设计中枢。Cadence Allegro做封装基板是行业标准工具之一光芯片的GDS和电芯片的GDS在Allegro里做芯片级规划、引线键合方案和阻抗连续检查是很多团队现在的标准操作。这个环节里Luceda导出的坐标和端口定义越规范Allegro里的工作就越顺。2.3 协同集成的落地形态数据流转与接口定义说了两边各管什么真正让它们协同起来的是数据流转的规范。我在实际项目里搭的流程是这样一条链第一步在Luceda IPKISS里选好硅光PDK搭出目标光链路比如一个MZM调制器加一段波导再加一个Ge探测器。跑完光学仿真之后把每个光电器件在目标工作点下的等效电路参数整理成一张“光电接口参数表”。第二步用IPKISS的模型导出功能把MZM和探测器生成Verilog-A文件。这个文件里记录的传输函数必须覆盖目标频段和偏置范围不要只导一个窄带S参数。我们第一次导出时就吃过亏S参数只覆盖到10GHz后来跑56Gbaud的PAM4仿真时完全不靠谱对不上实测曲线。第三步在Cadence Virtuoso里建一个顶层测试电路把TIA和驱动器画进去然后把刚才的Verilog-A模型当普通器件挂进网表。这里的重点是要定义一个统一的电学接口约定光输入端口用pd_in电输出端口用vout_p/vout_n所有模型端口命名必须一致否则联合仿真时网表会大量报port mismatch。第四步跑联合仿真。要么是电驱动输出波形喂进MZM模型的Vpi控制端看输出光信号要么是光信号经过链路到达探测器模型输出光电流进TIA再看电输出眼图。这取决于你关注的是发射端还是接收端也可以闭合起来跑完整的电-光-电链路。数据层面需要明确的接口定义包括接口项定义内容工程经验S参数文件格式Touchstone文件版本、频率单位、参考阻抗统一用50欧姆差分端口注意mode转换模型端口命名器和电端口统一命名规范和layout的pad名保持同源偏置点定义每个光电器件的DC工作点参数MZM的偏置点必须跟调制方式一致单位约定电压V、电流A、光功率W、频率Hz光功率单位最容易乱dBm和W换算不要只靠心算工艺版本光PDK和电PDK的版本号、模型角标光域和电域跑不同corner时要同步3. 从“能跑”到“跑得对”协同设计实操要点拆解3.1 打通第一条链路推荐的最小实验设计如果你所在团队第一次尝试Luceda和Cadence的协同设计我强烈建议不要一上来就全链路掐死先做一个最小的单通道验证闭环。我当时选的验证结构是一个连续激光器CW源加一个马赫-曾德尔调制器再加一段硅波导最后接一个Ge探测器探测器输出接到Cadence里一颗简单的跨阻放大器TIA。整个链路只有一个光通道、一个调制器、一个探测器不碰波分复用不加DSP连TIA都只用最简单的反馈电阻结构。选这个结构是有讲究的MZM和探测器的行为模型在物理上最成熟Verilog-A描述有标准模板可以参考TIA是电芯片模拟前端里基因最典型的模块几乎所有光电团队都做过整个闭环只要三个光电器件排查问题的时候不会有太多干扰变量。操作步骤如下第一步在IPKISS里完成光链路的原理图确认MZM消光比、插损探测器响应度、暗电流这些参数都来自同一个foundry PDK版本。然后用IPKISS的s_parameters分析跑一遍线性仿真确认波导段的损耗和反射指标在预期范围。第二步做联合仿真需要的模型导出。MZM的Verilog-A模型里输入是电压驱动信号输出是光功率的调制信号探测器的Verilog-A模型里输入是光功率输出是电流。这里我特别提醒一下光功率在Cadence网表里也是用电压值表示的也就是“1V代表1mW光功率”之类的约定必须白纸黑字写到项目的接口文档里。不然换个人接手很容易把光功率的单位搞混。第三步在Cadence里搭TIA电路。基于已有的电PDK设计好TIA的增益带宽后建立顶层testbench探测器模型的输出电流端口接到TIA输入TIA输出接一个高阻负载或者示波器探针模型。然后设置一个PAM4光信号激励跑瞬态仿真观察TIA的输出眼图。第四步对照光链路理论值检查仿真结果。如果MZM的ER6dB、探测器响应度0.8A/W那么进入TIA的电流摆幅可以估算出来TIA输出电压摆幅等于电流摆幅乘以跨阻增益。这个数字和仿真结果对不上就不是工具的问题而是模型参数或单位约定出了问题。3.2 联合仿真的关键配置和参数选择打通最小闭环之后进入正式联合仿真环节有几项配置你得花心思S参数频率范围。Luceda导出的波导和调制器S参数不要只覆盖到信号基频至少覆盖到目标速率的5倍频。56Gbaud的PAM4信号S参数至少要给到140GHz以上好一点的建议给到200GHz。低频端也要注意有些touchstone文件从10MHz才开始但调制器的低频响应和偏置点密切相关频率扫不到近DC后面做直流工作点仿真容易出幺蛾子。仿真档位设置。Spectre跑光电联合仿真如果模型里带了光学时延或者光反馈项时间步长控制不好容易不收敛。我的习惯是把strobe周期设置为符号周期的1/32最大步长设成符号周期1/256至少保证一个UI内有足够的采样点。代价是仿真时间变长但工程上这个代价值得花。偏置点检查。MZM的传输曲线Vpi和偏置点必须在联合仿真前单独校准。有一种典型错误是光链路仿真用推挽调制电驱动给的是单端信号结果MZM模型偏置点没跟着改输出光信号直接失谐了。这个没法靠仿真器自动发现只能靠人在testbench里定义好工作点。模型corner管理。Luceda的光学PDK和Cadence的电学PDK都有自己的工艺角。光波导的损耗角、探测器的响应度角和电晶体管的SS/FF角在联合仿真时必须同步设置。比如接收机灵敏度分析时要让光探测器响应度低角和TIA的MOS管慢角一起跑这才是能反映量产边界条件的组合。仿真数据后处理。Spectre输出的时域波形可以导出成CSV再用Python或者Luceda自带的工具重新绘图。我自己习惯用一段小脚本把探测器电流、TIA输出电压、眼图模板同时绘制出来一眼就能看出信号沿是哪里塌的。3.3 版图协同与LVS/LEC的一致性校验仿真层面的协同只是半条路版图层面的协同才是完整闭环。硅光芯片的版图和电芯片的版图虽然通常由不同团队绘制但它们之间有着强物理交互光芯片上电极焊盘的位置决定了电芯片的键合方案光波导和金属走线的距离决定了电磁串扰水平封装基板上的走线长度决定了高速信号完整性。在实践中我建议至少做三类检查第一类是坐标对齐检查。把Luceda导出的光芯片GDS和Cadence导出的电芯片GDS放进同一个版图环境里叠图检查所有需要键合或者倒装连接的pad是否精确对齐。检查时要注意原点坐标系统是否一致我们团队就遇到过Luceda版图原点在die中心、Cadence版图原点在左下角的情况叠图时整体偏了半个芯片幸好当时多看了一眼。第二类是层映射检查。光芯片GDS里的引脚和金属层定义和电芯片封装需要用的层定义经常不是一一对应。需要维护一张layer map表把Luceda工艺里的MZM_RF、MZM_RF-、PD_CATHODE这些层映射到Cadence或者Allegro里合适的电气层和器件类型。这个过程不要图省事每个映射都要有文字说明和review记录。第三类是设计规则联合检查。光芯片和电芯片单独的DRC都过了不代表键合后的组合结构没问题。比如焊盘尺寸符合光芯片工艺DRC但不符合电芯片键合工艺的推荐值或者光芯片MZM的T型电极和电芯片驱动器输出焊盘之间键合线长度导致额外电感超过预算。这些最好在投片前用版图级检查脚本扫一遍脚本逻辑不复杂但能省下一轮流片迭代。4. 协同仿真中常见的坑与排查实录4.1 眼图闭合先别急着怀疑激光器第一次跑通联合仿真的时候我们满心期待看到一个张开标准的PAM4眼图结果Spectre输出一看眼图闭合得只剩下一条缝。团队第一反应是怀疑激光器线宽参数设大了还有人怀疑是波导非线性效应没建模折腾了一天才发现是探测器模型的带宽不够——Verilog-A模型里少写了一段RC低通网络导致光电流信号的上升沿被严重拉缓。这个经历给我的经验是协同仿真的问题大多数不是原理问题而是模型精度和数据传递问题。看到一个不合理的结果先检查路径上每一个模型的带宽和参数范围再怀疑物理效应。尤其是从Luceda导出的等效电路模型到Cadence里被替换成通用行为模型时要仔细核对带宽表达式和寄生参数是否完整。另一类隐蔽问题是模型方向和主被动端口定义。光电器件模型被当成普通SPICE子电路使用时有人会把光输入输出端口接反。MZM的光输入端口接成了电信号源输出的光功率信号永远不变或者探测器模型的阳极和阴极接反光电流方向反了TIA输出端看起来像在反相放大。这种错误在网表层面不报错只有对照物理方向检查才能发现。4.2 Spectre不收敛、模型不定义、GDS对不上协同仿真最常见的三大工程问题我把处理办法列在这里Spectre瞬态仿真不收敛。现象是仿真器报ERROR (SPECTRE-16040)之类的收敛失败或者时间步长越来越小直到停摆。原因多半是光学模型里存在硬开关行为——比如MZM模型在某个驱动电压点传输函数变化太陡数值雅可比矩阵出现病态。解决办法有三条给模型加的驱动信号加一个有限的边沿速率不要用理想阶跃把模型的传输函数改写成连续可导的形式或者在仿真设置里把cmin值调大一点给节点人为补一个微小电容帮助收敛。从建模角度根治的话建议在Verilog-A里对传输函数做平滑处理比如MZM的cos传输函数加一个小的滚降项。光电模型在Cadence里“未定义”。出现这种现象通常不是模型文件本身的问题而是Cadence这边没有挂载正确的模型库。Luceda导出的Verilog-A文件需要放在Virtuoso能扫描到的路径里然后像标准PDK一样通过ahdlInclude语句引进去。还有一个常见错误是忘记在ADE环境里勾选Model Libraries里对应的库模型加载的根本不是当前工艺角的版本。GDS坐标对不上。Luceda导出的光芯片版图和Cadence后端工具里看到的光芯片占位不一致会导致封装评审时出现系统性偏差。这个问题通常出在坐标系原点和单位上。Luceda IPKISS默认布局单位是微米Cadence Virtuoso里某些流程默认用纳米导出的GDS在对方工具里整体缩放了1000倍看着“芯片太大”或者“芯片太小”。解决办法是在导出和导入时明确指定单位两边都固定用微米做交互单位并且以文字形式记录在项目的接口文档里。4.3 实测问题速查表从现象到根因我把过去一年踩过或者帮同事查过的典型问题整理成一个速查表遇到相似现象可以按图索骥现象优先检查项处理思路眼图张不开但直流增益正常光电模型带宽、RC网络缺失补全模型寄生参数核对S参数频率范围仿真器不收敛时间步长减小MZM模型传输函数太陡平滑传输函数、增加驱动信号边沿时间直流工作点漂移TIA输出饱和探测器极性接反或光功率单位错误核对端口方向、确认光功率电压映射联合仿真速度极慢模型阶数过高、仿真步长过密使用宏模型或等效电路降阶版图叠图偏移量大坐标原点、单位、层映射不一致统一坐标系、统一单位、检查layer map相同参数下两次仿真结果不同模型文件版本混用管理模型文件MD5建立版本库PAM4四个电平间距不均匀MZM偏置点不是正交偏置点重新校准工作点检查驱动信号幅值探测器输出电流偏小响应度参数单位和波长不匹配核对PDK参数表统一到同一波长4.4 协同流程里的版本管理比仿真本身更坑最后说一个不太像技术问题但很实际的事光电协同设计涉及两套PDK、两套仿真环境、大量Verilog-A模型和touchstone文件版本管理一团乱前面所有努力都可能白费。我们项目组的做法是建立三个层次的版本同步机制第一层是PDK版本同步。光PDK和电PDK的版本、发布时间、对应流片批次统一记录进项目Wiki。每次foundry升级PDK要求光、电两个团队同时评审评估对联合仿真结果和版图的影响。第二层是模型文件版本管理。所有从Luceda导出的Verilog-A、touchstone和netlist文件全部进Git文件名带日期或者版本号。严禁直接改文件后覆盖保存。我见过太多次“我改了几行模型代码结果全组人仿真结果都对不上了”的事故。第三层是仿真环境锁定。Virtuoso的ADE状态、模型库选择、仿真器版本、Python脚本库依赖能做“环境锁定”就尽量锁。特别是Cadence版本升级以后老项目的仿真结果可能因为模型解析差异发生微小漂移这种事不查根源根本找不到。5. 光电协同设计影响的不只是设计环节5.1 团队分工和评审流程随之改变工具链打通之后最先感受到变化的不是仿真精度而是团队协作方式。以前光团队和电团队各自评审光域的人看不懂电芯片的版图电域的人不知道光波导为什么会弯成这样评审会经常变成“两个房间的人互相传话”。协同设计流程跑起来后我们把“光电联合设计评审”设为硬性关卡每次评审时同一份联合仿真报告摆在所有人面前光电接口参数表、联合眼图和版图叠图放到同一页slide上讨论焦点一下子从推诿责任变成了排查技术问题。这个转变对团队里工程师的技能边界也提出了新要求。只需要懂光学流片的人不够了你至少能看懂TIA输入阻抗对探测器带宽的影响只懂模拟电路的人也不够了你至少要知道MZM的Vpi和ER是什么概念。好在协同流程本身提供了很好的学习曲线因为仿真模型和网表是同一个环境两边工程师都可以在同一个testbench里做参数扫描慢慢就建立起对“光/电接口”这个模糊地带的直觉。5.2 对PDK、foundry和电光封装的新要求协同设计集成也意味着foundry和PDK供应商需要提供更好的跨域支持。现在主流的硅光foundry都会同时提供光PDK和配套的器件SPICE模型但这个“配套”的质量参差不齐。有的PDK里探测器模型连结电容随偏压变化的曲线都没有有的MZM模型只有直流传输曲线没有交流频率响应这都让协同仿真变成无米之炊。作为设计方选型时我会多看几个维度一是foundry是否提供官方支持的Luceda PDK这通常意味着光电器件参数经过了流片验证二是PDK里是否包含用于Cadence仿真的器件模型和示例testbench三是foundry是否愿意提供光电器件的等效电路模型参数表比如探测器的带宽模型里是否包含RC参数和衬底寄生。这些看起来是“小事”但直接决定了协同设计流程能不能落地。封装层面也一样。光电合封co-packaged optics和硅光模块的可靠性很大程度上取决于光芯片和电芯片的互连设计。Allegro里做键合方案时键合线长度差异导致的电感感值变化必须在电芯片仿真里以封装寄生形式跑进去。这个环节光团队和封装团队必须把Luceda版图里的光口坐标、电芯片版图里的焊盘坐标、基板厂家的线宽线距规则合并到一套图里做评审。5.3 哪些项目最适合从协同设计切入理论上任何硅光项目都可以做联合仿真但工程资源有限我建议从这三类场景切入第一类是高速收发链路比如56Gbaud以上的PAM4或者相干系统的发射接收链路。这类项目里光电接口的带宽裕量和阻抗匹配非常敏感手工对接参数几乎注定出问题。第二类是光电联合的大规模阵列比如用于CPO的几十通道并行光引擎。单通道仿真还可以靠人工协调几十通道的通道间串扰、供电噪声交互必须靠统一的多通道联合仿真环境才能弄清楚。第三类是带有闭环控制和校准算法的智能光模块。AGC电路、偏置控制DSP、温度补偿环路这些数字/模拟控制逻辑和光学前端的相互作用只有在协同环境里才能仿真得明白。6. 给刚开始尝试协同设计团队的一点建议最后说点掏心窝子的话。Luceda和Cadence的光电协同设计集成听起来像是装个插件就能解决的事实际上更考验团队对模型、接口和流程的工程化管理能力。我见过一些团队买了两边的工具license请了原厂工程师来做演示工程跑通了一个demo就觉得万事大吉回头真正做项目时依然回到各干各的。问题不在于工具能不能连而在于有没有人去维护两套PDK的参数映射表、有没有人真的去写那几百行Verilog-A模型封装、有没有人愿意在建项目的第一天就把版本管理规则定下来。根据我个人经验最推荐的做法是先找一个最简链路例如单个MZM加单个探测器加一颗基础TIA拉一个类似“三周打通协同仿真闭环”的短期专项。过程中把每一个踩到的坑记成文档把每一份导出的模型放到版本管理里把每一次评审的联合仿真报告存档。等这个最小闭环真正稳定下来再去扩展通道数、加DSP、上波分复用。这个路线虽然慢一点但每一步都是扎实的不会在量产前夜突然翻车。光电协同设计的价值说到底不是设计流程的“自动化”而是让光芯片和电芯片这两套孤立的设计语言终于有机会在同一个仿真环境下互相理解。这个理解越早发生流片验证的代价就越低——项目团队省下的时间就是实打实的竞争力。 
长河君 · 2026/9/4 10:37:34 · 阅读 1.2k Luceda与Cadence光电协同设计：从参数对不上到联合仿真闭环
这几年做硅光收发链路设计我越来越确认一件事真正卡住项目进度的往往不是激光器功率不够也不是调制器带宽不够而是光芯片团队和电芯片团队各画各的等两边版图都出了才发现光口和电口的寄生参数、偏置条件、带宽裕量根本对不上。我最早干这活的场景很朴素——拿着Luceda里设计好的硅光PDK链路再切到Cadence Virtuoso里去画TIA和驱动电路两个工具之间靠手工截图和Excel表格传参数。一套PAM4的收发链路光域仿真和电域仿真各跑各的最后拼到一起总差一截信号完整性。后来我们尝试把Luceda和Cadence在流程上真正串起来做光电协同设计集成情况才明显好转。这篇内容不聊PPT架构只讲打通这套协同流程时实打实会碰到的机制、操作和坑。1. 光电“各画各的”时代我们到底吃了多少亏1.1 光芯片设计与电芯片设计的真实“温差”光芯片设计圈子里的主力工具这几年基本绕不开Luceda Photonics的IPKISS框架。它用Python把光链路搭成可编程的电路模型底层挂的是foundry提供的硅光PDK包含波导、MMI分束器、MZM调制器、Ge光电探测器这些光学元件最终能生成GDS版图也能跑S参数和时域光学仿真。这套工具链对光波导和版图约束的表述很清晰但它的强项不在这边——它对电学寄生、ESD保护、驱动器的输出阻抗这些事要么交给等效模型要么干脆不管。Cadence Virtuoso则是模拟/混合信号电路设计的老牌根据地。TIA、限幅放大器、MZM驱动器、LDD、SerDes收发前端都是在这里用PDK器件搭出来的。Virtuoso的优势在于SPICE级仿真足够精细能看PAM4眼图、能跑蒙特卡罗、能做版图寄生抽取后的后仿真。但问题也在这它的世界里没有“光”只有电压和电流顶多用行为级电流源或者光电流源去近似光电探测器的输出。两套工具一个管光、一个管电单独用都很强放到一起就成了断头路。光链路仿真给不出清晰的电学端口时序电链路仿真又不知道光学链路的实际插损、串扰和带宽于是两边设计人员只能靠口头对齐需求和猜。等GDS流片回来封装耦合完测试出来的误码率比仿真预估高一个量级才发现问题出在光电接口处的阻抗不匹配和带宽裕量不足。1.2 协同设计到底解决的是哪几类矛盾把Luceda和Cadence串起来本质上解决三类矛盾第一类是参数传递矛盾。光链路里调制器的半波电压Vpi、插入损耗IL、消光比ER直接决定电驱动电路的摆幅和功率预算探测器的响应度、暗电流、结电容直接决定TIA的增益和带宽设计。过去这些参数靠手工查表协同设计之后由同一套PDK数据模型统一管理S参数、等效电路和设计文档同源不会再出现光团队更新了器件版本电团队还在用旧参数画版图的情况。第二类是仿真域割裂矛盾。光链路里的时域波形比如MZM输出的PAM4光信号要用光学模型算但信号经过探测器之后进入TIA再到CDR的这一段又完全是电路仿真的事。协同集成之后可以把Luceda的光学行为模型嵌到Cadence Spectre的仿真网表里或者把电学仿真输出的驱动电压波形喂回Luceda的光学时域仿真形成闭合的“电-光-电”联合仿真环。第三类是版图一致性问题。硅光芯片的GDS里往往同时包含光波导版图和金属走线、焊盘、ESD结构这些电极结构必须和Cadence里封装的电芯片版图在尺寸、间距和压焊方案上对齐。协同设计流程里Luceda导出的光芯片版图可以带坐标信息回流到Cadence后端用来做封装基板或者芯片对准检查避免流片后才发现电极位置错半格这种低级错误。2. Luceda和Cadence在光电协同里各管哪一段2.1 Luceda IPKISS光域的中心化EDA平台IPKISS给我的感觉不是传统意义上点鼠标的工具它更像一个面向光子集成设计的Python框架。你用代码描述光链路拓扑先把foundry PDK里的元件实例化再把元件的端口通过波导连线然后跑光学仿真或者直接生成版图。这意味着光链路的每一个元件、每一段波导、每一个参数在项目里都是“可追溯的对象”不是在图形界面里画完就丢的孤岛。在光电协同集成场景里IPKISS最有用的能力有两块一块是光链路模型导出。IPKISS里有专门的模型生成模块能把复杂的光学链路编译成可以在外部EDA工具里调用的等效电学模型。常见的形式包括S参数Touchstone文件、Verilog-A行为模型、或者基于多项式近似的SPICE子电路。MZM可以被描述成一个电压控制的光学传输函数Ge探测器可以被描述成一个带结电容和串联电阻的光电流源。这些模型放到Cadence里就能让电路仿真器“看见”光学行为。另一块是版图数据带电气属性的导出。IPKISS生成的GDSII文件不只有多边形还可以带端口名、注释和层映射信息。你要是做过多芯片协同就会知道这些“看不见的信息”有多重要——后端工程师拿到光芯片的GDS之后能直接识别出哪个pad是射频信号输入、哪个pad是直流偏置、哪个区域禁止走线而不需要反复发邮件问光芯片工程师。2.2 Cadence Virtuoso电域的模拟/混合信号主战场Cadence这边负责的自然是电芯片设计。Virtuoso的架构大家熟原理图编辑、Spectre仿真、版图编辑、寄生参数抽取、物理验证各环节都有成熟的工具链。在光电协同流程里它承担的职责不只是“把电芯片画出来”更关键的是提供可信的电路级仿真环境和设计规则校验。具体来说Virtuoso在协同设计里有三个角色第一个是电学仿真宿主。Spectre仿真器可以挂载外部模型无论是厂商PDK的BSIM模型还是我们自己写的Verilog-A行为模型都能在统一网表里共存。Luceda导出的光电器件等效模型在Cadence里被当作普通的analogLib元件或者自定义pcell使用参与直流、瞬态、交流和谐波平衡仿真。第二个是数模混合验证平台。现代光模块的电芯片里不只有模拟前端还有数字控制逻辑、寄存器配置、DSP均衡器。Cadence的混合信号仿真平台比如XceliumVirtuoso ADE的协同允许数字RTL和模拟电路一起联合跑放在光链路场景里就能验证“数字AGC环路遇到光功率突变时TIA增益调整是否会导致光眼图塌陷”这类系统级问题。第三个是版图和封装设计中枢。Cadence Allegro做封装基板是行业标准工具之一光芯片的GDS和电芯片的GDS在Allegro里做芯片级规划、引线键合方案和阻抗连续检查是很多团队现在的标准操作。这个环节里Luceda导出的坐标和端口定义越规范Allegro里的工作就越顺。2.3 协同集成的落地形态数据流转与接口定义说了两边各管什么真正让它们协同起来的是数据流转的规范。我在实际项目里搭的流程是这样一条链第一步在Luceda IPKISS里选好硅光PDK搭出目标光链路比如一个MZM调制器加一段波导再加一个Ge探测器。跑完光学仿真之后把每个光电器件在目标工作点下的等效电路参数整理成一张“光电接口参数表”。第二步用IPKISS的模型导出功能把MZM和探测器生成Verilog-A文件。这个文件里记录的传输函数必须覆盖目标频段和偏置范围不要只导一个窄带S参数。我们第一次导出时就吃过亏S参数只覆盖到10GHz后来跑56Gbaud的PAM4仿真时完全不靠谱对不上实测曲线。第三步在Cadence Virtuoso里建一个顶层测试电路把TIA和驱动器画进去然后把刚才的Verilog-A模型当普通器件挂进网表。这里的重点是要定义一个统一的电学接口约定光输入端口用pd_in电输出端口用vout_p/vout_n所有模型端口命名必须一致否则联合仿真时网表会大量报port mismatch。第四步跑联合仿真。要么是电驱动输出波形喂进MZM模型的Vpi控制端看输出光信号要么是光信号经过链路到达探测器模型输出光电流进TIA再看电输出眼图。这取决于你关注的是发射端还是接收端也可以闭合起来跑完整的电-光-电链路。数据层面需要明确的接口定义包括接口项定义内容工程经验S参数文件格式Touchstone文件版本、频率单位、参考阻抗统一用50欧姆差分端口注意mode转换模型端口命名器和电端口统一命名规范和layout的pad名保持同源偏置点定义每个光电器件的DC工作点参数MZM的偏置点必须跟调制方式一致单位约定电压V、电流A、光功率W、频率Hz光功率单位最容易乱dBm和W换算不要只靠心算工艺版本光PDK和电PDK的版本号、模型角标光域和电域跑不同corner时要同步3. 从“能跑”到“跑得对”协同设计实操要点拆解3.1 打通第一条链路推荐的最小实验设计如果你所在团队第一次尝试Luceda和Cadence的协同设计我强烈建议不要一上来就全链路掐死先做一个最小的单通道验证闭环。我当时选的验证结构是一个连续激光器CW源加一个马赫-曾德尔调制器再加一段硅波导最后接一个Ge探测器探测器输出接到Cadence里一颗简单的跨阻放大器TIA。整个链路只有一个光通道、一个调制器、一个探测器不碰波分复用不加DSP连TIA都只用最简单的反馈电阻结构。选这个结构是有讲究的MZM和探测器的行为模型在物理上最成熟Verilog-A描述有标准模板可以参考TIA是电芯片模拟前端里基因最典型的模块几乎所有光电团队都做过整个闭环只要三个光电器件排查问题的时候不会有太多干扰变量。操作步骤如下第一步在IPKISS里完成光链路的原理图确认MZM消光比、插损探测器响应度、暗电流这些参数都来自同一个foundry PDK版本。然后用IPKISS的s_parameters分析跑一遍线性仿真确认波导段的损耗和反射指标在预期范围。第二步做联合仿真需要的模型导出。MZM的Verilog-A模型里输入是电压驱动信号输出是光功率的调制信号探测器的Verilog-A模型里输入是光功率输出是电流。这里我特别提醒一下光功率在Cadence网表里也是用电压值表示的也就是“1V代表1mW光功率”之类的约定必须白纸黑字写到项目的接口文档里。不然换个人接手很容易把光功率的单位搞混。第三步在Cadence里搭TIA电路。基于已有的电PDK设计好TIA的增益带宽后建立顶层testbench探测器模型的输出电流端口接到TIA输入TIA输出接一个高阻负载或者示波器探针模型。然后设置一个PAM4光信号激励跑瞬态仿真观察TIA的输出眼图。第四步对照光链路理论值检查仿真结果。如果MZM的ER6dB、探测器响应度0.8A/W那么进入TIA的电流摆幅可以估算出来TIA输出电压摆幅等于电流摆幅乘以跨阻增益。这个数字和仿真结果对不上就不是工具的问题而是模型参数或单位约定出了问题。3.2 联合仿真的关键配置和参数选择打通最小闭环之后进入正式联合仿真环节有几项配置你得花心思S参数频率范围。Luceda导出的波导和调制器S参数不要只覆盖到信号基频至少覆盖到目标速率的5倍频。56Gbaud的PAM4信号S参数至少要给到140GHz以上好一点的建议给到200GHz。低频端也要注意有些touchstone文件从10MHz才开始但调制器的低频响应和偏置点密切相关频率扫不到近DC后面做直流工作点仿真容易出幺蛾子。仿真档位设置。Spectre跑光电联合仿真如果模型里带了光学时延或者光反馈项时间步长控制不好容易不收敛。我的习惯是把strobe周期设置为符号周期的1/32最大步长设成符号周期1/256至少保证一个UI内有足够的采样点。代价是仿真时间变长但工程上这个代价值得花。偏置点检查。MZM的传输曲线Vpi和偏置点必须在联合仿真前单独校准。有一种典型错误是光链路仿真用推挽调制电驱动给的是单端信号结果MZM模型偏置点没跟着改输出光信号直接失谐了。这个没法靠仿真器自动发现只能靠人在testbench里定义好工作点。模型corner管理。Luceda的光学PDK和Cadence的电学PDK都有自己的工艺角。光波导的损耗角、探测器的响应度角和电晶体管的SS/FF角在联合仿真时必须同步设置。比如接收机灵敏度分析时要让光探测器响应度低角和TIA的MOS管慢角一起跑这才是能反映量产边界条件的组合。仿真数据后处理。Spectre输出的时域波形可以导出成CSV再用Python或者Luceda自带的工具重新绘图。我自己习惯用一段小脚本把探测器电流、TIA输出电压、眼图模板同时绘制出来一眼就能看出信号沿是哪里塌的。3.3 版图协同与LVS/LEC的一致性校验仿真层面的协同只是半条路版图层面的协同才是完整闭环。硅光芯片的版图和电芯片的版图虽然通常由不同团队绘制但它们之间有着强物理交互光芯片上电极焊盘的位置决定了电芯片的键合方案光波导和金属走线的距离决定了电磁串扰水平封装基板上的走线长度决定了高速信号完整性。在实践中我建议至少做三类检查第一类是坐标对齐检查。把Luceda导出的光芯片GDS和Cadence导出的电芯片GDS放进同一个版图环境里叠图检查所有需要键合或者倒装连接的pad是否精确对齐。检查时要注意原点坐标系统是否一致我们团队就遇到过Luceda版图原点在die中心、Cadence版图原点在左下角的情况叠图时整体偏了半个芯片幸好当时多看了一眼。第二类是层映射检查。光芯片GDS里的引脚和金属层定义和电芯片封装需要用的层定义经常不是一一对应。需要维护一张layer map表把Luceda工艺里的MZM_RF、MZM_RF-、PD_CATHODE这些层映射到Cadence或者Allegro里合适的电气层和器件类型。这个过程不要图省事每个映射都要有文字说明和review记录。第三类是设计规则联合检查。光芯片和电芯片单独的DRC都过了不代表键合后的组合结构没问题。比如焊盘尺寸符合光芯片工艺DRC但不符合电芯片键合工艺的推荐值或者光芯片MZM的T型电极和电芯片驱动器输出焊盘之间键合线长度导致额外电感超过预算。这些最好在投片前用版图级检查脚本扫一遍脚本逻辑不复杂但能省下一轮流片迭代。4. 协同仿真中常见的坑与排查实录4.1 眼图闭合先别急着怀疑激光器第一次跑通联合仿真的时候我们满心期待看到一个张开标准的PAM4眼图结果Spectre输出一看眼图闭合得只剩下一条缝。团队第一反应是怀疑激光器线宽参数设大了还有人怀疑是波导非线性效应没建模折腾了一天才发现是探测器模型的带宽不够——Verilog-A模型里少写了一段RC低通网络导致光电流信号的上升沿被严重拉缓。这个经历给我的经验是协同仿真的问题大多数不是原理问题而是模型精度和数据传递问题。看到一个不合理的结果先检查路径上每一个模型的带宽和参数范围再怀疑物理效应。尤其是从Luceda导出的等效电路模型到Cadence里被替换成通用行为模型时要仔细核对带宽表达式和寄生参数是否完整。另一类隐蔽问题是模型方向和主被动端口定义。光电器件模型被当成普通SPICE子电路使用时有人会把光输入输出端口接反。MZM的光输入端口接成了电信号源输出的光功率信号永远不变或者探测器模型的阳极和阴极接反光电流方向反了TIA输出端看起来像在反相放大。这种错误在网表层面不报错只有对照物理方向检查才能发现。4.2 Spectre不收敛、模型不定义、GDS对不上协同仿真最常见的三大工程问题我把处理办法列在这里Spectre瞬态仿真不收敛。现象是仿真器报ERROR (SPECTRE-16040)之类的收敛失败或者时间步长越来越小直到停摆。原因多半是光学模型里存在硬开关行为——比如MZM模型在某个驱动电压点传输函数变化太陡数值雅可比矩阵出现病态。解决办法有三条给模型加的驱动信号加一个有限的边沿速率不要用理想阶跃把模型的传输函数改写成连续可导的形式或者在仿真设置里把cmin值调大一点给节点人为补一个微小电容帮助收敛。从建模角度根治的话建议在Verilog-A里对传输函数做平滑处理比如MZM的cos传输函数加一个小的滚降项。光电模型在Cadence里“未定义”。出现这种现象通常不是模型文件本身的问题而是Cadence这边没有挂载正确的模型库。Luceda导出的Verilog-A文件需要放在Virtuoso能扫描到的路径里然后像标准PDK一样通过ahdlInclude语句引进去。还有一个常见错误是忘记在ADE环境里勾选Model Libraries里对应的库模型加载的根本不是当前工艺角的版本。GDS坐标对不上。Luceda导出的光芯片版图和Cadence后端工具里看到的光芯片占位不一致会导致封装评审时出现系统性偏差。这个问题通常出在坐标系原点和单位上。Luceda IPKISS默认布局单位是微米Cadence Virtuoso里某些流程默认用纳米导出的GDS在对方工具里整体缩放了1000倍看着“芯片太大”或者“芯片太小”。解决办法是在导出和导入时明确指定单位两边都固定用微米做交互单位并且以文字形式记录在项目的接口文档里。4.3 实测问题速查表从现象到根因我把过去一年踩过或者帮同事查过的典型问题整理成一个速查表遇到相似现象可以按图索骥现象优先检查项处理思路眼图张不开但直流增益正常光电模型带宽、RC网络缺失补全模型寄生参数核对S参数频率范围仿真器不收敛时间步长减小MZM模型传输函数太陡平滑传输函数、增加驱动信号边沿时间直流工作点漂移TIA输出饱和探测器极性接反或光功率单位错误核对端口方向、确认光功率电压映射联合仿真速度极慢模型阶数过高、仿真步长过密使用宏模型或等效电路降阶版图叠图偏移量大坐标原点、单位、层映射不一致统一坐标系、统一单位、检查layer map相同参数下两次仿真结果不同模型文件版本混用管理模型文件MD5建立版本库PAM4四个电平间距不均匀MZM偏置点不是正交偏置点重新校准工作点检查驱动信号幅值探测器输出电流偏小响应度参数单位和波长不匹配核对PDK参数表统一到同一波长4.4 协同流程里的版本管理比仿真本身更坑最后说一个不太像技术问题但很实际的事光电协同设计涉及两套PDK、两套仿真环境、大量Verilog-A模型和touchstone文件版本管理一团乱前面所有努力都可能白费。我们项目组的做法是建立三个层次的版本同步机制第一层是PDK版本同步。光PDK和电PDK的版本、发布时间、对应流片批次统一记录进项目Wiki。每次foundry升级PDK要求光、电两个团队同时评审评估对联合仿真结果和版图的影响。第二层是模型文件版本管理。所有从Luceda导出的Verilog-A、touchstone和netlist文件全部进Git文件名带日期或者版本号。严禁直接改文件后覆盖保存。我见过太多次“我改了几行模型代码结果全组人仿真结果都对不上了”的事故。第三层是仿真环境锁定。Virtuoso的ADE状态、模型库选择、仿真器版本、Python脚本库依赖能做“环境锁定”就尽量锁。特别是Cadence版本升级以后老项目的仿真结果可能因为模型解析差异发生微小漂移这种事不查根源根本找不到。5. 光电协同设计影响的不只是设计环节5.1 团队分工和评审流程随之改变工具链打通之后最先感受到变化的不是仿真精度而是团队协作方式。以前光团队和电团队各自评审光域的人看不懂电芯片的版图电域的人不知道光波导为什么会弯成这样评审会经常变成“两个房间的人互相传话”。协同设计流程跑起来后我们把“光电联合设计评审”设为硬性关卡每次评审时同一份联合仿真报告摆在所有人面前光电接口参数表、联合眼图和版图叠图放到同一页slide上讨论焦点一下子从推诿责任变成了排查技术问题。这个转变对团队里工程师的技能边界也提出了新要求。只需要懂光学流片的人不够了你至少能看懂TIA输入阻抗对探测器带宽的影响只懂模拟电路的人也不够了你至少要知道MZM的Vpi和ER是什么概念。好在协同流程本身提供了很好的学习曲线因为仿真模型和网表是同一个环境两边工程师都可以在同一个testbench里做参数扫描慢慢就建立起对“光/电接口”这个模糊地带的直觉。5.2 对PDK、foundry和电光封装的新要求协同设计集成也意味着foundry和PDK供应商需要提供更好的跨域支持。现在主流的硅光foundry都会同时提供光PDK和配套的器件SPICE模型但这个“配套”的质量参差不齐。有的PDK里探测器模型连结电容随偏压变化的曲线都没有有的MZM模型只有直流传输曲线没有交流频率响应这都让协同仿真变成无米之炊。作为设计方选型时我会多看几个维度一是foundry是否提供官方支持的Luceda PDK这通常意味着光电器件参数经过了流片验证二是PDK里是否包含用于Cadence仿真的器件模型和示例testbench三是foundry是否愿意提供光电器件的等效电路模型参数表比如探测器的带宽模型里是否包含RC参数和衬底寄生。这些看起来是“小事”但直接决定了协同设计流程能不能落地。封装层面也一样。光电合封co-packaged optics和硅光模块的可靠性很大程度上取决于光芯片和电芯片的互连设计。Allegro里做键合方案时键合线长度差异导致的电感感值变化必须在电芯片仿真里以封装寄生形式跑进去。这个环节光团队和封装团队必须把Luceda版图里的光口坐标、电芯片版图里的焊盘坐标、基板厂家的线宽线距规则合并到一套图里做评审。5.3 哪些项目最适合从协同设计切入理论上任何硅光项目都可以做联合仿真但工程资源有限我建议从这三类场景切入第一类是高速收发链路比如56Gbaud以上的PAM4或者相干系统的发射接收链路。这类项目里光电接口的带宽裕量和阻抗匹配非常敏感手工对接参数几乎注定出问题。第二类是光电联合的大规模阵列比如用于CPO的几十通道并行光引擎。单通道仿真还可以靠人工协调几十通道的通道间串扰、供电噪声交互必须靠统一的多通道联合仿真环境才能弄清楚。第三类是带有闭环控制和校准算法的智能光模块。AGC电路、偏置控制DSP、温度补偿环路这些数字/模拟控制逻辑和光学前端的相互作用只有在协同环境里才能仿真得明白。6. 给刚开始尝试协同设计团队的一点建议最后说点掏心窝子的话。Luceda和Cadence的光电协同设计集成听起来像是装个插件就能解决的事实际上更考验团队对模型、接口和流程的工程化管理能力。我见过一些团队买了两边的工具license请了原厂工程师来做演示工程跑通了一个demo就觉得万事大吉回头真正做项目时依然回到各干各的。问题不在于工具能不能连而在于有没有人去维护两套PDK的参数映射表、有没有人真的去写那几百行Verilog-A模型封装、有没有人愿意在建项目的第一天就把版本管理规则定下来。根据我个人经验最推荐的做法是先找一个最简链路例如单个MZM加单个探测器加一颗基础TIA拉一个类似“三周打通协同仿真闭环”的短期专项。过程中把每一个踩到的坑记成文档把每一份导出的模型放到版本管理里把每一次评审的联合仿真报告存档。等这个最小闭环真正稳定下来再去扩展通道数、加DSP、上波分复用。这个路线虽然慢一点但每一步都是扎实的不会在量产前夜突然翻车。光电协同设计的价值说到底不是设计流程的“自动化”而是让光芯片和电芯片这两套孤立的设计语言终于有机会在同一个仿真环境下互相理解。这个理解越早发生流片验证的代价就越低——项目团队省下的时间就是实打实的竞争力。