4. 协同验证概述
在CPO（Co-Packaged Optics，共封装光学）交换芯片项目中，验证对象不再是单一的数字芯片，而是由交换ASIC、光引擎、SerDes、驱动与跨阻放大器、微控制器固件、封装内光路以及板级电源与散热共同构成的异构系统。任何一个环节的模型偏差、时序错位或接口假设不一致，都可能在系统联调阶段集中爆发。协同验证（Co-Verification）正是为应对这种复杂性而提出的工程方法：它让不同抽象层次、不同实现载体、不同团队负责的模型在同一仿真或测试环境中同步运行、相互激励、共同判定，从而在流片和封装之前暴露跨域问题。
一、协同验证的定义与核心目标
协同验证是指在统一的验证平台中，将多个异构模型或真实器件按照其真实接口协议连接起来，使它们在同一时间轴上推进并交换激励与响应，最终对系统级行为做出联合判定。在CPO项目中，典型的协同组合包括：RTL与模拟/混合信号模型协同、芯片模型与光引擎行为模型协同、硬件与固件协同、仿真环境与实测仪器协同。
其核心目标可以归纳为四点：
- 跨域一致性：确认电域、光域、固件域对同一业务流的理解一致，例如链路训练状态机与光模块上电时序是否匹配。
- 接口契约验证：验证SerDes电气参数、管理接口寄存器映射、光引擎控制字等跨团队接口在真实时序下是否成立。
- 系统场景覆盖：在流片前运行链路建立、误码注入、热插拔、低功耗唤醒等系统级场景。
- 风险前移：把原本只能在实验室发现的问题提前到仿真和原型阶段，降低返工成本。
二、CPO项目中的验证层次
CPO协同验证通常分为四个层次，自下而上依次为模块级、子系统级、芯片级和系统级。层次越高，模型抽象度越高，但跨域交互越复杂。下表给出各层次的典型对象、关注点与常用手段。
| 验证层次 | 典型对象 | 核心关注点 | 常用手段 |
|---|---|---|---|
| 模块级 | SerDes TX/RX、CDR、光引擎驱动 | 电气参数、眼图、抖动容限 | SPICE/Verilog-A、定向激励 |
| 子系统级 | SerDes+光引擎链路、固件控制环 | 链路训练、状态机交互 | 混合信号仿真、UVM协同 |
| 芯片级 | 交换ASIC+管理接口+固件 | 寄存器访问、流量调度、中断 | RTL+固件协同仿真 |
| 系统级 | 芯片+光模块+板级+主机 | 端到端业务、热插拔、功耗 | 硬件在环、原型验证 |
层次划分的意义在于明确“在哪个层次验证哪类问题”。例如，光眼图质量应在模块级和子系统级解决，而链路误码在业务流下的统计特性则更适合系统级协同验证。若层次错位，往往导致仿真时间爆炸或问题漏检。
三、验证左移策略
验证左移（Shift-Left Verification）强调把验证活动尽可能提前到设计早期，以降低缺陷修复成本。在CPO协同验证中，左移并非简单提前跑仿真，而是通过模型先行、接口先行和场景先行来实现。
- 模型先行：在光引擎和模拟前端尚未完成时，先建立带真实接口时序的行为模型，使数字验证团队可以提前开展链路训练和固件交互验证。
- 接口先行：在RTL冻结前先冻结寄存器映射、管理接口协议和光引擎控制字格式，并用断言和参考模型固化契约。
- 场景先行：从项目初期就定义系统级场景清单，包括上电、链路建立、误码注入、热插拔和低功耗唤醒，并映射到各验证层次。
- 持续回归：将协同验证用例纳入 nightly 回归，配合覆盖率收敛看板，避免左移后缺乏持续反馈。
四、协同验证在CPO项目中的价值
CPO项目的显著特点是光电耦合、多团队并行、封装后不可轻易修改。协同验证的价值体现在三个层面：第一，提前暴露电光接口的时序与电平冲突，避免封装后返工；第二，让固件团队在芯片可用前就能验证控制流程，缩短 bring-up 周期；第三，为系统级性能评估提供可重复、可观测的仿真环境，支撑架构决策。
下面用一个简化的协同验证信号链示意，说明数字域、模拟域、光域与固件域如何在统一平台中交互。图中展示了从主机业务流到光输出的主要路径，以及固件通过管理接口对链路状态的监控与调节。
五、常见误区与复盘要点
协同验证在实践中容易走入几个误区。其一是“模型越精细越好”，导致仿真速度无法支撑系统场景；正确做法是按验证目标选择抽象度，并在关键接口处保留足够精度。其二是“接口口头约定”，缺少机器可检查的契约，导致联调时才发现寄存器位定义不一致。其三是“只跑通不度量”，没有联合覆盖率和缺陷逃逸统计，无法判断协同验证是否真正有效。
综上，协同验证在CPO项目中承担着连接数字、模拟、光与固件的枢纽作用。明确验证层次、坚持验证左移、建立统一时间基准与联合判定机制，才能把光电协同的复杂性转化为可控的工程流程，为后续流片、封装和系统 bring-up 提供可靠保障。