铁路专用芯片服务器端可重用开发环境的研究

马 盼，林子明

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

1 概述

国内对轨道交通列控系统的研究起步较晚，前期的研究工作主要是引进并消化国外成熟的技术，后期研究工作的主要目标是在借鉴外国技术的基础上形成符合国内列车特点的具有自主知识产权的轨道交通列控系统[1]。经多年技术积累，已经实现了轨道交通控制系统从系统级到硬件板卡级的自主化，并实现软件系统自主化，但在底层核心芯片，尤其是专用芯片领域，仍严重依赖进口。当前，国内轨道交通列控系统底层芯片受国外“卡脖子”问题突出，实现高速铁路核心技术体系自主创新成为铁路人的首要目标。

一枚芯片从设计开发到封装成片会经过一系列的仿真制造流程，传统的产品“试错式”开发和“迭代式”开发不适用于芯片开发[2]，设计过程中的设计漏洞造成的设计缺陷以及后期流片出现的工艺缺陷会直接影响开发效率和成本。铁路专用芯片一般以标准协议控制芯片或定制数字芯片为主，随着芯片规模和复杂度的提高，PC 机在性能和存储上已不能满足芯片前端设计仿真需求，越来越多的项目会采用Linux 操作系统服务器进行开发。为解决以上问题，本文分别从数字芯片前端设计与仿真验证两个方面分析开发环境的需求，并提出了基于linux 服务器端构建的稳定可重用开发环境。

2 芯片设计与仿真测试对开发环境的需求

为保证芯片功能的正确性，在铁路专用芯片研发过程中采用研发人员异构机制[3]，芯片前端设计与仿真验证流程如图1 所示[4]。研发人员根据芯片功能需求书共同划分出功能列表。设计人员根据功能列表确定芯片的目的、效能，进行规格制定后，设计芯片细节，使用硬件描述语言(Verilog，VHDL)将电路描述出来。测试人员则根据功能列表确定测试目标、测试平台及工具和测试方法，制定测试规格后，使用验证语言(SystemVerilog)搭建测试平台和测试用例。当设计代码完成后，测试人员对这些代码进行功能仿真验证，检验代码实现与产品需求和设计规格的正确性、完备性和一致性[5]。

图1 芯片前端设计与仿真验证流程Fig.1 IC Chip front-end design and simulation verification process

2.1 设计环境需求

通常，数字芯片前端功能设计开发与传统的数字系统设计不同，是按照自顶向下（top-to-down）设计思路规划芯片的层次结构，再分模块、分层次地进行设计描述[6]。首先确定顶层模块的设计，然后进行子模块的详细设计，而在子模块中可以调用库中已有的模块或设计过程保留下来的知识产权（IP）实例，最后通过电子设计自动化（Electronics Design Automation，EDA）工具配合相应测试平台进行层级编译和仿真。设计开发过程中代码文件主要分为3 类，分别为设计文件、库文件和IP 核文件。其中设计文件随仿真验证动态变化，需进行代码版本管理。仿真调试时设计人员侧重关注于设计代码的功能逻辑，对开发环境的需求更倾向于简单的仿真命令、简便的工具调用和直观的仿真结果。

2.2 仿真环境需求

在数字芯片前端功能仿真验证中可先对设计代码进行静态测试，初步检查代码是否符合设计规则，随后采用动态测试，检验设计逻辑功能是否符合设计需求[7]。动态测试是采用不同测试方法（如创建定向测试用例或随机测试用例[8]）在不同层级实现相同的测试目标，该测试由一系列测试用例驱动，这些测试用例通常是面向某些场景的一组约束，为了实现测试平台可重用性，在构建测试平台时，可将专用测试用例与承载测试用例的通用组件分组管理。仿真调试后经过修改更新的代码为避免出现已测试通过的用例在当前版本不能通过的问题，需要进行回归测试来保证代码功能的一致性。为提高仿真效率，开发环境在满足设计需求的同时还需满足从单测试用例到测试用例集的批量仿真。

3 开发环境设计结构

本文提出的linux 服务器端可重用开发环境，利用目录与文件树结构助力研发人员快速建立设计仿真通路，并采用高效的自动化脚本实现启动设计仿真中所需要的一系列工具，并对设计的仿真结果进行归纳管理。

如图2 所示，该环境中的文件采用目录树形结构实现管理，开发环境内所有进行中的工作及最终交付内容位于目录与文件树的项目根中，项目主干为当前开发路径，而设计仿真过程的阶段性结点可将代码版本打标签存于版本管理中。左子树项目主干下的分支目录根据代码种类和实现功能的不同，对代码文件进行了初步分类，其中设计组件目录存放设计文件，库目录下用来存储工程所需的库文件，IP 核目录下主要存放IP 核生成后缀为.v 文件、.vhd 文件和IP 核生成的网表等文件，设计人员可根据芯片规格和计划存放相应文件。

图2 目录与文件树结构Fig.2 Directory and file tree structure

验证组件目录、测试用例目录和文件列表目录组织结构相似，在各自分支下存放着基于模块级或芯片级命名的结点。验证组件目录的叶结点为不随测试用例变化而变化的通用测试平台文件。对于设计人员，测试平台文件至少包括顶层文件，对于验证人员，测试平台文件除了顶层文件，还包括验证平台中的组件，如接口、驱动和计分板等。测试用例目录在结点模块级或芯片级路径下存放该级所有测试用例，每个测试用例再单独建立结点，存放自己的用例文件。文件列表目录的叶结点为测试平台文件列表、设计文件列表、库列表以及覆盖率配置列表4 种文件，分别存放着开发环境中所有代码的相对路径。

开发环境的核心脚本独立存于脚本目录中，用于自动加载文件并调动EDA 工具进行仿真。仿真执行目录存放着测试用例配置文件和生成文件（Makefile)，同时还存放编译仿真运行工程生成的过程文件以及波形文件等。考虑到芯片后仿真，开发环境中增加后端目录用于建立后端工程。

4 开发环境启动与应用

不同的目录存放不同代码，如何将这些代码调动起来，主要依靠仿真执行目录中的Makefile 和测试用例配置文件及核心脚本。开发环境启动流程如图3 所示，当在仿真执行目录输入make 相关命令时，开发环境启动核心脚本自动读取配置文件，并根据相应测试用例或测试用例集的配置参数组织好相关文件进行编译、仿真和调试，并将生成的日志、波形和覆盖率等结果存在仿真目录下。

图3 开发环境启动流程Fig.3 Development environment start-up process

其中，通过Makefile 命令可以为所有的目标文件创建依赖关系链[9],将命令和参数编号传递给核心脚本，在本文提出的开发环境中主要有单测试用例仿真命令、单测试用例调试命令、测试用例集批量仿真命令和清理文件命令。

开发环境中所有层级的测试用例使用测试用例配置文件来管理，如表1 所示。在配置文件中可对每一个测试用例进行编号，并指定不同的配置，配置项包括模块或芯片层级命名、库文件包命名、种子类别和相关编译参数等。如表1 中所列测试编号1 为对芯片S 输入测试用例1 的仿真配置，该芯片S 采用55 nm 工艺库，测试平台采用UVM 方法学自动随机化测试，并在仿真过程中开启仿真波形下载和覆盖率统计。

表1 测试用例配置文件Tab.1 Test case conf iguration f ile

仿真命令输入后，核心脚本首先根据参数编号寻找测试用例配置文件中相应测试用例或测试用例集，再通过相应配置行模块或芯片层级命名和库文件包命名检测相应文件列表是否存在，最后基于命令和编译参数调用EDA 工具，并在仿真目录中创建所属测试用例子目录存储过程文件。过程文件主要有编译日志、波形文件、覆盖率文件及仿真分析记录。

以SM4 算法模块[10]在开发环境中的设计仿真为例，将设计与测试相关文件准备完毕，并存放于相应的目录位置后，先通过单测试用例仿真命令运行测试，得到仿真分析记录报告和波形文件，再通过单测试用例调试命令可调用如图4(a)所示的EDA 工具进行代码和波形的调试。待设计进入稳定阶段后，可通过测试用例集批量仿真命令，对所有测试用例进行并行回归测试后，可以查看如图4(b)所示的覆盖率报告。

图4 调试工具与覆盖率报告Fig.4 Debugging tools and coverage reports

5 总结

铁路专用芯片设计开发过程中存在大量仿真测试寻找漏洞，测试数据重复性高且工作量大，在设计进入稳定阶段后，存在大量回归仿真测试。从仿真测试运行时间来看，如一个小型的铁路专用芯片，10 条测试用例串行运行时间可达252 720.1 s，采用本文开发环境并行回归测试时间，可降到串行运行时间的10%，大大缩短了仿真测试周期。本文的服务器端可重用开发环境满足大部分专用铁路芯片设计开发需求，便于使用、管理和协同工作，支持从模块级到芯片级、RTL 级到门级网表、单测试用例到测试用例集的设计与仿真，并在列控、轨道电路、点式设备、安全计算机等多个系统专用芯片项目中得到验证。该开发环境的重用性大大减少了测试环境的构建工作和维护成本，在保证芯片可靠性同时提升了开发效率。