刘光宇，马 盼，刘肖婷，孟博洋，林子明

（1.北京全路通信信号研究设计院集团有限公司，北京 100070；2.北京市高速铁路运行控制系统工程技术研究中心，北京 100070）

1 概述

国内铁路技术飞速发展，铁路运营里程不断攀升，各种复杂的运行环境对列车控制技术的要求也更为严格。当前，由于可移植性高及便于开发等特点，现场可编程逻辑门阵列（Field Programmable Gate Array，FPGA）得到了广泛应用。随着列控逻辑功能的不断增加，对其验证的要求也在不断提高。传统的FPGA 开发工具仿真的方式已逐渐不能完成其全序功能的测试[1]。

近年来，验证技术的不断发展，通用验证方法学（Universal Verification Methodology，UVM）凭借其标准化、层次化和可重用性等特点开始占据主导地位。同时借助服务器端高并行度的特点，可实现更快速的测试和迭代。本文针对列控应答器传输模块中的解码板FPGA 逻辑，实现了以SystemVerilog 语言构建的UVM 验证平台，可实现对待测设计（Design Under Test，DUT）的快速迭代和功能覆盖。

2 验证对象特征分析

应答器传输模块（Balise Transmission Module，BTM）主要实现对编码报文的译码功能，其总体设计框架如图1 所示。输入的编码长报文或短报文FSK_in 信号首先进入先入先出数据缓存器（First In First Out，FIFO），控制模块（control）检测到FIFO 非空情况，开始读取其内部数据，并在达到其判定条件后开始在解码模块（decode）中进行译码过程。译码完成后的结果送入随机存储器（Random Access Memory，RAM）模块，等待CPU 总线进行读取。

图1 BTM硬件设计结构Fig.1 BTM hardware design structure

BTM 内置通信模块信箱（Mailbox），含发送FIFO Tx 与接收FIFO Rx，可方便与其他设备进行数据通信。同时为保证设备运行的可靠性，BTM 还内置自检模块，定时进行报文自检和天线自检处理，以保证设备的正常运行。同时，其内部还有丰富的地址映射，方便对速度、距离、时间戳等进行配置或读取。

3 验证平台实现

UVM 面向所有数字设计，涵盖从模块级到芯片级，从ASIC 到FPGA，从控制逻辑、数据通路到处理器的全部场景[2]。基于其灵活的环境类，可方便实现组件的层次结构化扩展。

典型的验证平台如图2 所示。其主要包含激励序列（sequence）、主代理（i_agent）、参考模型（reference model）、计分板（scoreboard）、从代理（o_agent）5 大部分[3]。事务级激励序列经由序列生成器送入驱动器，转化成信号级激励序列后驱动DUT，主监视器检测DUT 端口激励，将其转为事务级激励后送入参考模型，参考模型计算得到的参考结果（golden result）送入计分板，与从监视器采集到的DUT 输出进行比较，从而判定DUT执行结果的正确性。

图2 BTM验证平台结构Fig.2 BTM verification platform structure

BTM 报文的编码及解码主要依据欧洲编码规范，其实现较为复杂，测试采用的编码后报文部分源于《应答器传输系统测试规范》（TB/T 3544-2018），尤其针对特定错误报文的输入，需遵循严格的编码规则，测试所需的异常报文均由规范中获取。针对此类情况，本测试对平台进行了优化，取消参考模型的数据通路（如图2 虚线箭头所示），改由驱动器直接将参考结果送入计分板（如图2 空心箭头所示）。

验证平台的控制主要采用python 语言实现，测试用例的所有参数，含标号、测试序列、顶层模块指定、波形使能和覆盖率使能等，均在表格中呈现，使平台的控制更为简单直观。依托图表工具集pandas，可方便实现对表格进行读取，生成所需的编译命令和仿真命令。同时依据进程池工具集multiprocessing，可在服务器资源允许的情况下实现对任意数量案例的并行仿真。

4 随机驱动加定向用例的验证实现

4.1 随机激励

随机激励[4]主要采用报文编码生成器，生成可译码的报文。由于产生的报文都是典型报文，其严格符合编码规范，大规模随机测试对功能覆盖及代码覆盖影响较小[5]。对随机仿真仍难以覆盖的情况，可通过大量报文生成后再进行软件筛选的方式进行实现。

报文编码生成器主要采用C 语言实现，可将830 bit 长报文编码为1 023 bit，或将210 bit 短报文编码为341 bit。为保证编码的完备性和正确性，生成器还内置了译码模块，对编码后的长短报文进行译码并判定其正确性。SystemVerilog引入的直接编程接口（Direct Programming Interface，DPI），可方便进行SystemVerilog 语言与C/C++语言间的相互调用。为方便实现各种报文的组合情况测试，本文没有采用DPI 模式，而是将长短报文分别进行生成，组合后送入测试平台。针对长短报文编解码长度不一致情况，同时兼顾异常报文无法解码的情况，将报文设计为“编码+分隔符号+解码/异常标号”组合，并按字符串模式进行读取。在检测到指定分隔符号后，将编码报文送入驱动器，将解码报文送入计分板，驱动器依据编码报文字符串长度选用对应位宽变量进行接收，计分板对正常解码报文同样按字符串长度选用对应位宽变量进行接收，并进行相应比对。

4.2 定向测试

定向测试[6]主要完成BTM 中特定场景的测试，如报文异常注入、自检、Mailbox 通信、边界溢出等情况。通过在定向用例中添加小规模随机的情况，可实现覆盖率的迅速提升。

定向常规报文测试主要针对选定的报文进行测试。报文按其功能可划分为正常长报文、正常短报文、异常长报文、异常短报文，不同类型的报文编码长度和解码长度均不相同。为便于进行混合测试，激励序列中生成的报文同样为字符串形式。驱动器得到激励序列后，将其进行分割，编码报文驱动DUT，解码后报文或异常标号通过UVM 的config 机制直接送入计分板中。DUT 解码后的报文或异常标号与计分板中的参考结果进行比对，即可迅速对结果正确性进行比对，同时对错误情况可实现迅速定位。

BTM 运行过程中需进行定期自检，自检含天线自检和报文自检两大部分。对于天线自检，其会占用报文输入端口；对于报文自检，其会占用CPU总线接口。为最大限度检测自检功能正确性，与实际相比，仿真中显著缩短了自检间隔。设计中引入uvm_event 方法，当检测到总线忙时则处于等待状态，直至总线空闲时占用总线，读取报文输出结果或相应地址空间，并在使用结束后释放总线，如此可方便解决接口调用时的冲突问题。

针对译码过程中寻找报文头模块覆盖率低的情况，采取将报文依次移位译码的方法，并依据仿真速度对用例进行拆分。针对11 转10 译码模块覆盖率低的情况，可生成大量随机报文并筛选符合要求的情况，有效地减少仿真时间，提高仿真效率。

典型定向用例对行覆盖率和分支覆盖率的影响如图3 所示，其中横轴表示的定向用例为同类型用例的整合。可以看出，针对性的添加定向测试用例，可以实现代码覆盖率的快速提升，并迅速达到99%以上，针对未覆盖情况，设计补充案例，即可实现代码的全覆盖。

图3 典型定向用例对代码覆盖率的影响Fig.3 Impact of typical cases on code coverage

5 验证结果

本次仿真在linux 平台下进行，采用VCS 仿真工具实现。使用随机加定向的测试模式，可实现覆盖率的快速收敛。在保证功能覆盖完备性的前提下，本文共设计定向案例48 个（含为加速仿真而拆分的24个案例），即可实现指定的覆盖率。经设计人员确认，排除无效和冗余情况，指定的行和分支情况代码可实现100%完全覆盖，代码覆盖率如图4 所示。

图4 BTM代码覆盖率Fig.4 BTM code coverage

6 结论

以BTM 解码板作为验证对象，基于UVM 的验证平台，采用随机驱动加定向测试的组合模式，实现了对代码功能的仿真测试。与传统FPGA 验证模式相比，验证平台可以实现不同功能的测试场景，并可实现组合情况的覆盖，同时可对疑问或错误情况进行快速定位。而自动化的测试方法，可大大缩短前期测试与后期迭代的时间成本，从而保证验证周期和功能覆盖的完备性。