自适应跨平台PSS 中间件架构及开发

王 锋，王 磊，张栗榕

（新华三半导体技术有限公司 西安研究所，陕西 西安 710075）

0 引言

随着半导体行业的高速发展，集成电路的规模和设计的复杂性在不断地增大，使得芯片设计的正确性很难保证，与此同时，芯片验证也越来越困难，成为了现代芯片开发周期的瓶颈[1]。随着芯片验证方法学的发展，传统的电子设计自动化（Electronic Design Automation,EDA）验证发展到与硬件加速（Emulator，EMU）平台和FPGA（Field Programmable Gate Array）原型验证平台混合的验证手段。而如何在模块级、子系统级、系统级等不同层级和EDA、EMU、FPGA 不同类型测试台（Test‐bench，TB）上进行测试激励的复用，确保不同平台验证的一致性，成为了新的挑战[2]。

为了实现测试激励的有效复用，继UVM（Universal Verification Methodology）之后，Accellera 标准组织推出了便携式测试和激励标准（Portable Stimulus Standard，PSS），其目标是提供一个独立的测试激励来源，并在更高的抽象级别上定义激励和场景，从而实现跨层级和平台的场景描述和测试激励复用。其主要的特点如下：

(1) 通过PSS 建模在更高抽象级别上指定激励和测试，可定义面向CPU（Central Processing Unit）和各类接口协议的复杂组合场景。

(2) 可以方便地生成随机组合场景的C/C++或者SV (SystemVerilog）代码，通过编译并加载C/C++如案卷程序实现CPU 的验证场景，通过调用验证IP（Verification Intellectual Property,VIP）或硬件加速VIP（Accelerated VIP，AVIP）实现对特定协议接口的激励。

(3) PSS 场景模型不仅可应用于模块级、子系统级和系统级EDA 测试台，还可以用在EMU、FPGA 平台，为不同级别的平台产生相同的激励，实现了测试激励复用，确保了验证的一致性。

目前最新的PSS 2.0 标准协议保留了“C”“CPP”和“SV”这三个目标编程语言标志符，用于指定代码块的预期编程语言为C、C++和SystemVerilog，同时提供这三种语言的数据类型绑定（binding）方法，这样可以方便地生成C、C++和SystemVerilog 随机化代码[3]。

对于相同的总线或协议接口，通过开发PSS 模型并在指定的目标SV（SystemVerilog）代码中调用特定的VIP 接口任务，可实现通过特定VIP 接口随机化的激励。但是，不同的测试台可能会集成不同的VIP/AVIP，它们的调用流程也有区别，如果切换VIP/AVIP，则需要在PSS 模型中定义不同的具体调用VIP/AVIP 的细节，这大大增加了PSS 建模人员的工作量，而且导致加大了PSS模型与测试台具体实现的耦合度，无法完全实现PSS 模型只关注高层抽象场景和易于移植的需求。

此外，汇编语言是CPU 指令机器码的别名，指令机器码和汇编指令通常都会同时发布在CPU 指令手册中，对于CPU 指令集的验证，与C/C++语言相比，汇编语言具有更简洁、更高效、更全面的优势。但是，当前的PSS标准并没有为汇编语言预留相应的标志符，特别是没有提供标准的数据类型绑定方法，这不便于生成CPU 指令验证所需的各类随机汇编代码。

为了解决以上两类问题，本文提出了添加中间件（Midware）层的验证平台架构，在PSS 高层级抽象建模的基础上，可实现VIP/AVIP 的灵活选择和自适应切换，并支持不同种类的CPU 汇编指令随机验证，实现了PSS建模与具体测试台实现方法的解耦，能够更充分发挥PSS 标准的优势。

1 基于中间件层的PSS 验证平台架构

1.1 验证平台架构介绍

如图1 所示，本文提出由场景描述层、中间件层和测试台（Testbench，TB）层三个层次组成的基于PSS 的验证平台架构，充分发挥PSS 场景抽象定义和测试具体实现。

图1 基于PSS 中间件层的验证平台架构示意图

1.2 场景描述层

场景描述层由PSS 相关组件和工具构成，充分发挥PSS 对验证场景抽象化的能力，对验证目标场景进行较高层次的定义，使得场景描述层的组件可复用，与模块级、子系统级、系统级EDA 环境，以及EMU 硬件加速和FPGA 原型验证等多个平台实现一致的验证场景。场景描述层定义的场景与接口协议的具体硬件实现无关。

场景描述层的构成如图2 所示，主要包括：

图2 场景描述层示意图

(1) PSS 工具

PSS 工具可使用基于PSS 2.0 标准版本的商用工具，包括PSS 语法编译器compiler 和解算器solver，负责编译、随机化并生成基于中间件层的SystemVerilog 和C代码。

(2) PSS 核心库

PSS 标准定义了符合PSS 2.0 标准的PSS 核心库（PSS core library），包括组件类型、数据类型、函数和属性，为常见的PSS 应用程序（如内存和寄存器读写访问等）提供标准的可移植功能和使用程序。

(3) PSS 模型库

针对常用标准协议，例如PCIe、以太网接口、AMBA总线等，本文提出新的架构，开发PSS 模型组件构成PSS模型库，实现了对标准协议基本操作、资源管理、目标语言生成等功能。这里生成的PSS 模型库目标语言也高度抽象化，直接与中间件层的接口对接，隐藏了测试台的具体实现方式。

(4) 汇编指令PSS 模型

利用PSS 2.0 标准保留的C 目标编程语言标志符，本系统也实现了平台无关的汇编指令PSS 模型，该指令模型对汇编指令抽象化，可生成C 目标语言格式的特定指令代码，该代码可通过中间件转化为面向特定CPU 的可编译可执行汇编指令，在一定程度上抽象化CPU 指令，隐藏了具体CPU 的汇编命令格式。

(5) 场景定义PSS 模型

基于PSS 核心库、PSS 模型库和PSS 汇编指令模型，验证场景PSS 模型的开发人员可根据验证目标芯片的实际需求，通过使用PSS 模型库中预定义的协议模型组件，定义各种复杂交叉场景，包括并不限于接口协议的组合场景、汇编指令的组合场景等。PSS 场景模型开发人员不需要了解测试台的具体实现方式和具体CPU 类型，可将工作内容聚焦于场景定义。

1.3 中间件层

不同类型或不同层级的测试台可能使用不同的VIP，因此场景描述层定义的验证场景需要映射到不同的测试台层以实现其具体功能。本文提出的中间件层实现PSS 抽象场景定义到不同测试台的映射。

中间件层的基本架构如图3 所示，主要包含两大类中间件：一类是进行VIP/AVIP 适配的adapter 工具，支持多种接口和总线协议；另一类是代码转换工具，实现汇编代码生成。

图3 中间件层示意图

(1) VIP/AVIP adapter

VIP/AVIP adapter 是一组SV 和C/C++的API 接口库。高层抽象的PSS 模型所生成的SV/C++代码被集成到测试台前，通过该adapter 调用具体的底层VIP 测试组件，实现验证的一致性。

(2) 汇编转换工具

PSS 2.0 标准协议保留了“C”“CPP”和“SV”这三个目标编程语言标志符，用于指定代码块的预期编程语言为C、C++和SystemVerilog，同时提供这三种语言的数据类型绑定，这样可方便地生成C/C++和SystemVerilog 随机化代码，但PSS 标准并没有为汇编语言预留相应的标志符，特别是没有提供标准的数据类型绑定，这不便于生成CPU 指令验证所需的随机汇编代码。为了更好地生成随机汇编代码，本系统利用C 目标编程语言标志符，生成的C 语言函数对应不同的CPU 汇编指令，通过函数参数扩展实现汇编指令参数随机化。PSS compiler/solver 工具将PSS 模型转换为随机参数的C 代码之后，代码转换工具对其参数进行识别，转换为随机汇编指令。这样，当使用不同的CPU 选项时，得到的汇编代码会有所不同，对CPU 指令组合场景进行建模时，可直接使用PSS 模型库中的汇编指令模型，在一定程度上隐藏了不同CPU 类型之间的区别。

1.4 测试台层

测试台包含除test 外的验证框架和组件实现，包括接口、驱动、监测、参考模型、结果判定等，可以是模块级、子系统级或系统级验证的UVM 平台，也可以是EMU 硬件加速、FPGA 原型验证平台。不同的测试台可能挂接不同的VIP/AVIP 实现对协议接口的驱动。对由中间件层生成的具体的汇编代码进行编译、加载、运行和检查功能。

测试台层编译或运行时需要加载中间件生成的SV、C 和汇编代码，架构如图4 所示。

图4 测试台示意图

2 中间件层的实现

2.1 VIP/AVIP adapter 库

VIP/AVIP adapter 库作为场景模型与底层测试台不同种类VIP/AVIP 之间的桥梁，实现了各类标准协议的封装。

以PCIe 高速接口数据传输为例，VIP/AVIP adapter库为PSS 场景描述层提供类似于以下通用SystemVer‐ilog 调用接口：

task vip_pcie_send_data(input pcie_send_cfg cfg);

PSS 场景描述层中的PSS 模型库中针对PCIe 高速接口协议，定义一组抽象模型用以描述PCIe 功能场景。如PCIe 数据传输模型有如下PSS 模型库实现的参考伪码：

当抽象场景中需要进行PCIe 数据传输时，只需要调用对应的action 即可实现。如PCIe 重复数据发送的PSS场景模型参考伪码如下：

由此可见，编写PSS 场景模型时，只需调用PCIe 模型库的send_data action，不需要关心验证平台类型、具体底层实现以及集成了哪个VIP/AVIP，有效实现了高层抽象特性。

另一方面，adapter 库针对不同的PCIe VIP 和AVIP预置了对应的task 或function 实现，如以下针对某特定商用PCIe VIP，有如下adapter 参考伪码：

当验证平台自动化工具生成测试台代码时，通过选择VIP 选项指定特定VIP/AVIP，其对应的adapter pack‐age 代码会被工具自动附加到测试台文件列表中，对测试台进行编译和运行仿真时会自动加载并使用该VIP adapter 代码。

通过以上方法，VIP/AVIP adapter 库有效地将场景抽象层与测试台VIP/AVIP 连接到一起。

2.2 汇编代码转换工具

汇编代码转换工具实现了指令模型到特定CPU 类型汇编代码的实现。

以load 指令为例，场景描述层中的PSS 模型库中定义了以下抽象模型，用以定义load 汇编指令：

当抽象场景中需要调用汇编load 指令时，只需要调用对应的action 即可实现。如DMA 传输场景模型可按如下方式编写：

以上PSS 场景模型代码经PSS 工具进行compile/solve 之后，生成以下测试场景C 伪代码：

这里0xf8xxxxxx 是PSS 工具随机化之后得到的地址，r3/r5 是随机化得到的CPU 通用寄存器名。上述C 伪代码无法使用C 语言编译器直接进行编译，需要通过汇编代码转换工具进行转换。

汇编代码转换工具可对应多种不同的CPU 类型，当验证平台自动化工具生成测试台代码时，通过选择CPU选项指定特定CPU 类型，其对应的转换工具会自动添加到测试台工具链中，当对测试台的CPU 软件进行编译时会自动转换为对应的汇编代码。转换结果示例如下：

如果选择某RISC-V CPU 类型时，生成的汇编代码如下：

如果选择另一种CPU 类型时，生成的汇编代码如下：

可以看到，当使用不同的CPU 选项时，得到完全不同的汇编代码。因此，通过使用PSS 模型库中的指令模型，在一定程度上隐藏了不同CPU 类型之间的区别，实现了CPU 指令的高层抽象特性。

3 基于中间件层的PSS 验证平台开发

开发的中间件及整个PSS 验证平台集成在验证平台管理系统中，相关的系统架构、工具链及流程如图5所示。

图5 基于中间件的PSS 验证平台管理系统

开发和运行基于中间件的PSS 验证平台流程：

(1) 中间件开发

生成adapter 库和汇编代码转换工具。

(2) PSS 验证场景模型开发

使用PSS 模型库，开发各种验证场景PSS 模型。

(3) 测试台开发

使用验证平台自动化工具，选择正确的测试台类型、VIP 选项和CPU 选项，自动生成相应的验证平台框架，支持自动集成适配的VIP/AVIP、VIP/AVIP adapter 和汇编代码转换工具。

(4) 启动仿真或回归测试

主要流程如下：

① 调用PSS compiler/solver 对验证场景PSS 模型进行处理，生成随机化之后的测试场景代码（SV 和C代码）；

② 调用汇编代码转换工具对特定CPU 上运行的C代码进行转换，生成对应的汇编代码；

③ 对验证平台进行编译；

④ 启动仿真或者回归测试。

步骤(3)通过选择不同选项，可以生成集成了不同VIP、面向不同CPU 类型的EDA 或EMU 验证平台架构，这些不同的验证平台都可以使用相同的PSS 场景模型（步骤(2)开发得到的），从而实现验证场景和激励的跨平台一致性。

4 结论

综上所述，通过开发基于中间件架构的PSS 验证平台，本文实现了以下目标：

(1) 验证场景和激励在跨平台时保持一致性，适用于CPU 指令验证和使用通用VIP/AVIP 的验证场景；

(2) 验证场景模型开发和测试台开发的完全解耦，通过中间件层将底层实现与场景定义彻底隔离开，充分发挥了PSS 高层建模特性，便于跨项目、跨平台扩展移植。

(3) PSS 定义汇编指令场景，与C 语言相比，提升了对CPU 指令验证的效率和完备性。

(4) 完善PSS 模型库、VIP/AVIP adapter 库和汇编语言转换工具，可对应各类VIP 和CPU 类型。当芯片升级换代时，可灵活替换自适应验证环境中CPU 和VIP 类型，大大提高了验证环境的继承性。

(5) 基于PSS 验证中间件的验证平台开发和使用，由验证管理平台进行统一管理，实现了对第三方PSS 工具的灵活调用以及对标准的验证平台自动化构建流程，大大提高了基于PSS 验证方法学的模型和验证平台搭建和扩展效率。

(6) 测试台只需集成VIP/AVIP 对应的adapter，其代码量增长有限，对测试台编译和仿真效率影响可以忽略。

(7) 目前本系统主要应用于芯片硅前（pre-Silicon）验证（包含EDA verification、EMU 和FPGA validation），将来可扩展、统一硅后（post-Silicon）validation 及其他验证、测试平台。