面向汽车SerDes链路的OpenGMSL验证助力提升车载SoC、FPGA及系统项目的开发效率

“ 现代车辆依赖各种摄像头、传感器、显示屏、电子控制单元、域控制器以及中央计算平台，这些设备之间必须可靠地交换海量数据。这些链路可支撑高级驾驶辅助系统、自动驾驶功能、数字座舱、环视摄像头、驾驶员监控以及车载信息娱乐系统等各类应用。
”

车载SerDes链路：不止于基础数据传输测试

作者：Mohith Haridoss，SmartDV Technologies全球销售总监

现代车辆依赖各种摄像头、传感器、显示屏、电子控制单元、域控制器以及中央计算平台，这些设备之间必须可靠地交换海量数据。这些链路可支撑高级驾驶辅助系统、自动驾驶功能、数字座舱、环视摄像头、驾驶员监控以及车载信息娱乐系统等各类应用。

OpenGMSL设计IP与验证IP为开发具备互操作性的车载视频及高速数据连接解决方案提供了基于标准的底层支撑。基于GMSL2和GMSL3技术，OpenGMSL v3.0为半导体企业、整车厂商以及系统开发人员提供了一套通用规范，用于构建符合标准的根节点与叶节点实现方案，从而实现多供应商之间的互操作性。

在SmartDV的OpenGMSL实现方案中，根节点（Root）代表中央计算侧端点，叶节点（Leaf）代表外接的边缘侧端点；二者具体的收发职责取决于配置的流量方向与实际应用场景。有效的OpenGMSL验证绝不能仅校验数据能否传输至链路对端。验证团队必需对根节点与叶节点行为、正向及反向通信、所支持的链路速率、多路数据流、链路拓扑、编码、纠错、时间同步、低功耗状态、内容保护以及系统级恢复能力开展验证。

为什么说OpenGMSL验证至关重要？

车载系统正在接入更多摄像头、更高分辨率显示屏、雷达与传感器输入、域处理单元以及中央计算资源。这就对高带宽链路提出越来越高的要求：要求其能够在广泛分布于不同位置的组件之间传输多种类型业务数据流量，并且在超出常规功能运行的各类工况下仍保持稳定可预期的性能，这些工况包括数据损坏、时钟偏差、流量中断、启动故障以及电源状态切换等场景。

即便是一项开放标准，仍需严谨的验证

OpenGMSL v3.0旨在提供一套开放、可直接落地实现的规范，兼容成熟的GMSL2与GMSL3技术，从而允许半导体厂商与汽车开发团队基于这套共享标准去开发相应产品，而不必完全依赖于单一厂商的闭环实现方案。但开放规范并不代表可以省去验证环节，这反而让协议合规性与互操作性测试变得更为重要，因为OpenGMSL联盟就将强制性合规测试视作保障多供应商互操作性的组成部分。

一套设计在对接内部自研模型进行测试时可能运行正常，但在对接其他厂商的实现方案时依然可能暴露出问题。因此，验证工作既要覆盖单个器件的行为，也要完成完整链路的互操作性验证，需对可选功能、支持模式、边界条件、时序容差，以及目标系统所需的GMSL2和GMSL3技术配置兼容性开展测试。这有助于降低风险：实现方案能够通过内部测试，但集成到更大的车载生态系统后则出现失效。

软件定义汽车离不开高可靠的高速链路

软件定义汽车架构越来越倾向于将传感器和显示屏与解析、生成其数据的中央处理资源进行解耦。在这类架构中，车载SerDes链路可传输摄像头与图像传感器数据、视频和显示业务流量、包封以太网流量、I2C与SPI控制流量、UART及GPIO边带通信、I2S/TDM/PDM音频流、时序同步信息，以及配置和诊断数据。验证工作必须确保这些业务数据流量能够共存，不会出现数据损坏、丢失、路由错误或是不可预测的时延问题。

开发团队也可按应用场景探索SmartDV的IP产品，获取更多面向车载SoC、域控制器、传感器系统以及中央计算平台的设计IP与验证IP。

OpenGMSL验证的关键技术挑战

根节点与叶节点：需独立验证，也需联合验证

一条OpenGMSL链路包含功能互补的根节点与叶节点组件。根节点负责协调与所连接叶节点端点之间的通信，从而根据配置的应用场景，支持正向数据流传输以及反向链路边带通信。

每个组件首先必须完成独立验证。根节点必须产生合规的前向链路行为，并正确处理反向链路数据流量。叶节点必须正确接收并解码前向链路数据流，同时生成合规的反向通信链路。随后，验证工作必须确认这两个组件作为完整链路可以正常工作，包括启动、配置、速率选择、编码、数据路由、同步、错误处理以及故障恢复。

前向与反向数据流量必须保持协同

OpenGMSL支持高速前向传输，同时可通过反向链路来承载配置、控制、同步以及其他边带数据的通信。验证团队必须确认：前向与反向数据流量能否同时工作；控制操作是否正确关联目标端点；反向链路活动是否会影响前向链路的吞吐量或时序；即便反向流量出现中断或格式异常，系统能否正确对其进行处理，且不会损坏正在传输的视频或传感器数据流。

一条链路即便可以正常传输视频，如果控制或诊断通道的行为不可预测，依然会出现系统级故障。

多数据流类型带来复杂的路由需求

OpenGMSL链路可同时传输视频或传感器数据流，以及封包以太网、控制、音频数据流量，每一类数据流对带宽、时序、排序和数据交付都有着不同的要求。验证工作必须确认：在数据流量并发、数据流组合动态变化、突发情况以及不同数据流量类型发生资源竞争的场景下，各类数据流能够被正确识别、路由、优先级调度、传输与重建。

单个数据包可能看似正常，但整个系统仍可能失效，原因在于数据流路由错误、报文乱序交付，或是受到其他来源的数据流量的干扰。

必须覆盖不同链路速率与信号传输模式

SmartDV 的OpenGMSL解决方案支持3Gbps、6Gbps和12Gbps的前向链路速率，根据所选速率采用NRZ与PAM4信号模式，反向链路则由187.5Mbps通道提供支持。更高的传输速率意味着验证过程中需要生成、监测、校验与重建的数据流量随之增大，同时编码、前向纠错、时钟、同步以及缓存机制的重要性也随之提升。

验证环境的配置必须与目标工作模式保持一致，需要针对设计所支持的每一档速率，对链路启动、与速率相关的编解码、不同配置间切换，以及链路性能下降或中断条件下的表现等一系列项目进行验证。不能想当然认为某一链路速率下运行正常的设计，在所支持的全部模式下也必然正确。如果仅测试标称速率或者某一种常见流量模型，会造成验证计划存在明显盲区。

链路拓扑改变验证环境

车载系统可能采用不止一组点对点连接。SmartDV的OpenGMSL验证IP（VIP）支持单链路、分配器、聚合、菊花链以及多链路拓扑，每种拓扑对路由、链路启动、同步、寻址以及故障隔离都提出了差异化的要求。

验证工作需要确认一系列设计事项，例如每个端点均可被正确识别和配置、数据流能够送达目标节点、聚合与分配器配置不会导致数据丢失或报文乱序问题、菊花链设备按照正确顺序完成初始化；同时还要确认单个节点发生故障时，不会造成其他节点出现不可控行为。验证计划应当贴合目标整车架构所采用的实际拓扑，而不能仅依赖简单的双节点测试。

链路启动与同步行为必须具备可预测性

在链路能够传输有效业务数据之前，互连组件必须建立通信、识别选定工作条件、同步时钟，并进入所需的工作状态。OpenGMSL验证需要能覆盖所支持的标准和快速启动行为两种模式，同时还要能够应对响应延迟、状态不稳定、启动过程中断、反复启动重试，以及意外复位后的恢复等各类场景。

精准时间同步与基于反向参考的时钟同样需要专项验证。摄像头、传感器和显示系统通常依赖于物理分离组件之间的时序协同。一条可正确传输数据但丢失了时序对齐的链路，依旧无法满足目标应用的使用要求。

必须对编码与前向纠错进行专项测试

编码、加扰以及前向纠错有助于保护各条高速车载链路的数据完整性。SmartDV的根节点与叶节点IP可提供OpenGMSL链路运行所需的分方向9B/10B编码、加扰以及里德-所罗门（Reed‑Solomon）FEC功能。

验证工作必须确认在各种正常工况下编解码是否正确，还应该主动注入错误以校验错误检测、支持范围内的纠错、上报不可纠错状态、纠错能力耗尽后的行为表现，以及帧或数据流损坏之后的恢复。仅确认FEC逻辑能够在正常数据流量下运行是远远不够的。当链路遭遇无法纠正的错误时，设计也必须做出可预测的响应行为。

功能安全要求明确定义的故障响应

OpenGMSL可应用于安全相关的车载系统，在此类系统中，摄像头与传感器数据支持驾驶员辅助以及自动驾驶功能。因此，验证工作必须应对设计是如何对故障进行检测、上报、隔离并完成恢复，诸如视频和传感器数据的损坏或丢失、链路意外断开、时钟与同步失效、非法状态跳转，以及在启动或唤醒过程中发生的故障。

每一类故障对应的预期响应行为都应当在验证计划中予以明确定义。检测出错误仅仅是需求的一部分。周边系统必须获取充足信息使应用进入合适的安全状态或降级工作状态。

如需了解车载及其他安全关键型设计的更多相关考虑要点，可阅读《IP Core Considerations for Safety‑Critical Applications》（安全关键型应用的IP核考量因素）。

内容保护与低功耗状态带来更多验证层面

车载显示与信息娱乐系统可能需要对视频或音频内容进行保护处理。SmartDV的OpenGMSL产品支持可选的HDCP 1.4与HDCP 2.3内容保护。验证工作需要确认配置端点的初始化流程、HDCP认证、受保护数据流处理、所采用的加解密行为是否正常，同时覆盖认证异常以及认证中断场景。安全和内容保护测试应当纳入主验证环境，而不是作为独立的末期收尾检查。

车载系统还会频繁在工作状态和低功耗状态之间切换。SmartDV的OpenGMSL根节点与叶节点IP支持休眠（Sleep）与待机（Standby）状态，以在无需链路满负荷工作时降低功耗。验证必须覆盖低功耗状态的进入与退出、配置信息保存、唤醒行为、时钟恢复、链路重建，以及状态切换过程中出现的各类错误工况。链路在完整复位后可正常工作，但从部分功耗模式或待机状态恢复时，仍有可能出现故障。

验证团队应该如何开展OpenGMSL验证工作

1. 定义完整的链路架构

在开展测试之前，需要对目标架构进行文档化梳理，内容涵盖根节点与叶节点端点、链路方向、拓扑结构、数据流、支持速率、时钟、同步、内容保护、功耗状态以及功能安全需求。此举可以避免在模块级验证阶段遗漏关键的系统行为。

2. 独立验证根节点与叶节点组件

在组件联调之前，需分别对链路两端开展验证。根节点测试应该确认串行器正常工作、前向数据流生成、反向数据接收、配置处理以及错误上报。叶节点测试则应该确认解串器工作、前向数据流重建、反向链路生成、同步、路由以及故障响应。独立测试有助于在引入拓扑、系统或互操作变量之前，更高效地定位协议层面的问题。

3. 验证完整的双向链路

功能单元级功能验证完成之后，就开展根节点与叶节点的联合验证，同时跑通前向与反向数据流量，并确认控制信令交互不会意外干扰高带宽数据流。测试应该包括常规流量、最大吞吐量、异步事件、响应延迟、传输中断，以及反复启动与恢复循环等场景。

4. 测试支持的所有速率与拓扑结构

验证工作需要覆盖最终产品所支持的每一条链路的速率与拓扑结构，包含不同速率对应的编码、FEC行为、时序、启动流程以及性能极限。针对多节点系统，需要测试端点接入、移除、故障、复位与重新配置，确认在数据流量模式与系统状态发生变化时，路由逻辑始终保持正确。

5. 多并发数据流压力测试

将视频、传感器、封装以太网、串行控制、音频以及GPIO数据流量组合在一起，以创建贴近真实的系统级工作负载，动态调整数据流大小、时序、带宽、优先级以及传输方向。验证工作需要确认：即便前向链路正在持续传输高速视频或传感器数据，更低带宽控制流量依旧能够保持正常响应。

6. 将错误注入纳入主测试计划

从项目初期就应当将错误注入纳入考量，覆盖符号损坏、编码错误、FEC可纠正与不可纠正错误、同步丢失、链路中断、非法状态跳转以及非预期复位等场景。每一项注入的错误都需要明确定义预期响应，包含状态上报、故障隔离、故障恢复，以及软件或上层系统需要执行的任何处理动作。

7. 验证各端点之间的时序与同步机制

车载摄像头、传感器以及显示屏可能依赖于共享的或协同的时序。验证工作需要确认反向链路参考时钟行为、高精度时间同步、启动对齐、时钟漂移响应、重新同步，以及链路中断后的恢复行为，上述测试需要在真实数据流量负载下开展，而不仅仅在链路空闲环境下进行。

8. 对功能安全与低功耗场景联合验证

安全与电源管理行为不能认为是相互独立的验证项目。需要通过使用组合场景将其与常规协议运行进行联合测试，例如电源状态切换过程中发生链路故障或多路数据流正在传输时执行复位。组合场景能够暴露出独立功能测试无法发现的故障。

9. 验证系统级集成

完成协议与组件的验证之后，将OpenGMSL模块集成至更大规模的系统级芯片（SoC）和车载子系统中。系统级测试应该确认摄像头与传感器数据能够送达正确的处理模块、显示数据能够传输至目标端点、控制与诊断软件可获取准确的状态信息，以及故障能够上报至对应的安全或管理层。该环节用于确认符合协议规范的链路，在集成到真实系统架构之后依然能够可靠运行。

10. 使用协议感知型验证IP

内部自研OpenGMSL驱动、监控器、协议检查器、数据流路由、覆盖率模型、拓扑支持、错误注入以及兼容性测试需要投入巨大的工程人力。进一步了解验证IP如何通过减少从零开始搭建协议底层基础设施的工作量来提升SoC的验证效率。

具备协议感知能力的验证IP可提供相应的基础设施，以生成数据流量、监控链路行为、验证协议合规、故障注入以及进行覆盖率统计。在可扩展SoC验证中采用可复用的验证IP允许研发团队将经过验证的协议组件、覆盖率模型以及测试平台基础设施复用到不同车载平台和后续迭代产品中。当被集成到规范化UVM验证环境中时，OpenGMSL验证IP支持研发团队把更多时间投入到产品专属架构、功能安全行为以及系统集成验证工作周期上。

SmartDV的OpenGMSL设计IP与验证IP（VIP）

为了支持开发车载视频、传感器、高级驾驶员辅助系统、自动驾驶以及车载信息娱乐系统的研发团队，SmartDV提供了一套协同配套的OpenGMSL设计IP与验证IP产品组合：

·OpenGMSL根节点设计IP：可作为中央计算侧端点，支持前向链路与反向链路的全部功能。

·OpenGMSL叶节点设计IP：可作为外接边缘侧端点，实现互补的链路功能。

·OpenGMSL仿真验证IP（Simulation VIP）：支持多种链路速率和多种拓扑架构下根节点和叶节点之间的通信验证，包含多数据流流量、编码与前向纠错（FEC）验证、HDCP版权保护验证、功能覆盖率、协议监控，同时提供一套完整的测试用例集。

其中设计IP支持3Gbps、6Gbps和12Gbps的前向链路速率，搭配一条187.5Mbps的反向链路，支持多种视频格式、灵活链路拓扑、可选内容保护，以及支持ASIL标准车规开发的功能安全机制。

SmartDV的协同配套方案为工程团队提供用于设计的功能IP，以及用于验证该IP的协议感知型验证组件。进一步了解设计IP与验证IP之间的区别。

并不是所有的车载SerDes实现方案都要求同一种拓扑结构、主机接口、数据流配置、内容保护特性以及性能指标。SmartDV依托自研的SmartCompiler™技术，基于客户的设计需求、ASIC或FPGA目标与系统架构，对根节点和叶节点IP进行配置与优化。进一步了解SmartDV面向可定制IP的IP Your Way理念以及SmartCompiler技术。

OpenGMSL v3.0是一个全新的标准，但车载SoC及系统项目需要在正式量产落地之前就提前开展架构规划、硬件实现与验证工作。SmartDV的早期用户合作计划为符合条件的设计团队提供机会，在项目还处于定义阶段就讨论OpenGMSL根节点IP、叶节点IP以及验证IP的需求，从而有助于团队在方案难以修改之前，就完成拓扑结构、功能特性、接口、定制化以及验证需求的评估。

总结

基于GMSL2与GMSL3技术，OpenGMSL为可互联互通的车载视频及高速数据链路提供了基于标准的底层基础。完整的OpenGMSL验证不能仅验证基础的串行器、解串器等基础数据流量。验证团队还必须处理以下工作：

·根节点与叶节点的独立及组合链路行为，包含前向和反向数据流量协同。

·支持所有的链路速率、信令模式和拓扑配置

·提供真实数据流量场景下的视频、传感器、控制、音频和数据流的并发传输

·启动、时钟、时间同步、编码和前向纠错

·内容保护、功能安全和低功耗状态切换

·多供应商互操作性和车载系统级集成

使用配套的设计IP与验证IP能够帮助研发团队基于统一的协议基础开展工作，减少内部基础设施开发工作量，并在车载SoC开发周期的更早阶段构查明架构或集成问题。