使用虚拟原型和UVM测试平台进行早期软件开发和端到端系统验证

SNUG Taiwan 2020 2020 15 页

使用虚拟原型和UVM测试平台进行早期软件开发和端到端系统验证

会议: SNUG Taiwan 2020 作者: Hsu-Yao Huang, Chun-Hung Lai, Shih-Min Chang, Li-Sheng Chang, Shih-Che Lin, Jin-Lin Liu (Silicon Motion Technology Corp.) 页数: 15 源文件: SNUG_TW_Software_SiliconMotion_paper.pdf

摘要

基于虚拟原型 Virtual Prototyping的系统级仿真使硬件/软件集成和系统验证能够在实际硬件或芯片可用之前进行。然而，构建平台模型所需的工作量和端到端原型制作的启动时间仍然昂贵。本文讨论了一种混合 SystemC/SystemVerilog 仿真方法，以提高 IP 级功能验证生产力，并总结了应用 Synopsys PCIe 虚拟 I/O 解决方案进行系统级硬件/软件协同验证和性能验证时应注意的问题和解决方案。实现了一个基于虚拟化 PCIe 的 SSD 固态硬盘系统，以展示其仿真速度、时序精度、行为/时序模型所需的实现时间以及系统级虚拟原型的启动时间。

目录

1. 引言 2. 系统级软件开发和验证的挑战 2.1 IP 建模工作量 2.2 硬件调试、软件调试和执行控制 2.3 PCIe 设备开发挑战 2.4 速度与精度之间的权衡 3. 提出的解决方案的概念和用法 3.1 通过 SystemC 和 SystemVerilog 集成提升 IP 验证生产力 3.1.1 用于验证的 UVM 测试台 3.1.2 TLM 和 RTL 协同仿真之间的接口 3.1.3 SystemC 和 SystemVerilog 集成的能力/收益 3.2 通过 Synopsys PCIe 虚拟 I/O 解决方案进行系统级虚拟原型 3.2.1 使用 Synopsys 工具的实现流程 3.2.2 实现流程中的问题和解决方案 3.3 动态仿真模式切换 4. 结果 5. 结论和未来工作 6. 参考文献

1. 引言

软件开发成本已成为电子设计中的主导因素，特别是对于需要复杂固件处理闪存磨损和损坏的 SSD 设计系统。虚拟原型 Virtual Prototyping基于TLM 事务级建模（Transaction Level Modeling）已被业界广泛采用，用于实现早期软件开发和性能评估。

TLM-2.0 提出了两种事务级建模风格：松散定时（LT）和近似定时（AT）。LT 建模风格（即功能模型）非常适合软件集成、验证和调试。AT 建模风格（即性能模型）标注了时序行为，适用于分析和优化软件栈中的性能调优。

本文使用 Synopsys Virtualizer/VDK 建模 SSD 设计系统，展示虚拟原型如何解决固件开发和验证的具体挑战。

2. 系统级软件开发和验证的挑战

2.1 IP 建模工作量

事务级模型对于新的、遗留的或第三方 IP 有时并不存在。构建 SystemC IP 模型的工作量仍然昂贵。一种有前景的解决方案是使用 SystemC 和 TLM 创建 IP 模型，其建模工作量远低于 RTL 开发。最关键的问题是确保 RTL 和 SystemC 事务级模型的一致性。通过使用为 IP RTL 设计验证开发的相同 SystemVerilog UVM 测试台，也可以确认 SystemC IP 模型的功能性、完备性和寄存器精度。

2.2 硬件调试、软件调试和执行控制

硬件感知软件开发更难诊断问题。管理闪存的软件称为闪存转换层（FTL），需要处理地址转换、磨损均衡、坏块管理、纠错、多 LUN 操作和交错等功能。虚拟平台本质上是软件，可提供高系统可见性和控制力。软件调试器可以附加到目标处理器核心，追踪真实软件镜像的行为。所有硬件信号和控制状态都可以表示为软件变量并在软件调试器中观察。

2.3 PCIe 设备开发挑战

Synopsys PCIe 虚拟 I/O 解决方案为 IP 特定软件启动提供了优秀的解决方案。PCIe 相关模型和驱动程序的早期可用性为 IP 特定软件开发、测试和硬件/软件集成提供了早期且功能完整的解决方案。它还允许故障注入以测试系统的反应，并可轻松扩展到大规模并行测试。

2.4 速度与精度之间的权衡

系统级硬件/软件协同验证需要在仿真速度和时序精度之间取得平衡。通过更高的抽象可以获得更高的仿真速度，但这会导致时序信息损失从而影响仿真精度。

3. 提出的解决方案

3.1 通过 SystemC 和 SystemVerilog 集成提升 IP 验证生产力

3.1.1 UVM 测试台： UVM 通用验证方法学基于 SystemVerilog 硬件验证语言（HVL），引入了约束随机激励和覆盖率度量。SystemVerilog UVM 测试台承诺提高验证生产力，因为相同的激励可以在不同的抽象层次上重用。

3.1.2 TLM 与 RTL 协同仿真接口： 关键步骤是使用称为 Transactor（Xtor）的事务级接口集成 SystemC 事务级模型和 RTL。Xtor 将信号级总线协议转换为事务级 payload，表示两个通信接口的完整语义并处理两个域之间的同步。

图1：SystemC和SystemVerilog集成复用UVM测试台 图2：AXI Xtor概念视图

AXI 协议有五个独立通道：读地址（AR）、读数据（R）、写地址（AW）、写数据（W）和写响应（B）。AXI Master Xtor 从信号域接收读写请求，然后转换为以通用 payload 表示的读写事务。

3.1.3 集成的能力/收益： - 复用 SystemC LT 模型作为早期 UVM 测试台创建的参考模型 - 复用 SystemVerilog UVM 测试台确保 RTL 和 SystemC TL 模型的一致性 - 复用 SystemC AT 模型用于 RTL IP 设计的子系统性能验证

图3：复用SystemC AT模型用于RTL IP设计的子系统性能验证

3.2 Synopsys PCIe 虚拟 I/O 方案

图4：SSD设计系统的Synopsys PCIe虚拟I/O方案

紫色部分表示 Synopsys 提供的 IP：代理设备、PCIe VM 适配器、CPU 模型和 PCIe 端点设备模型。

3.2.2 实现流程中的问题和解决方案（表1摘要）：

问题解决方案
1. PCIe EP设备连接PCIe VM适配器时无法识别使用默认BAR0_MASK值，固件无需重新设置
2. 调试器无法观察ARM fast model的TCM将内部TCM设为false，改用系统总线上的通用内存
3. 调试器只能观察64位数据宽度的slave模型使用ARM fast model内部集群层的initiator socket
4. Virtualizer端无法在前一次host写未完成时读host将阻塞传输接口函数和回调函数解耦为两个SC_THREAD；Synopsys后续更新了PCIe EP模型和VM适配器
5. Host无法接收相同中断向量号的中断发送额外的MSI-X消息（设置Bit 31）作为中断结束信号

3.3 动态仿真模式切换

多粒度模型可以实现仿真速度和时序精度之间的各种权衡。本文包含动态仿真模式切换功能，在运行时启用/禁用时序模型。在到达性能分析关注点之前，采用 TLM LT 模式快速到达关注点；当 OS 启动后实际测试运行时，可按需将一个或多个 IP 动态切换到 TLM AT 模式。

4. 结果

时序精度：

图5：行为模型和时序标注的开发时间

表2 — 主要IP模型的时序精度：

IP模型NVMeDRAMFlashBusDMA
时序精度(%)93.0%*71.1%96.7%*93.6%63.8%

*按最后请求评估而非按事务评估

DRAM 精度下降由于读 outstanding 和读 FIFO。DMA 精度下降由于读 outstanding 和读/写交错。

开发时间： - NVMe：18个月（8月Xtor + 9月功能 + 1月时序） - Flash：8个月（1月Xtor + 4月功能 + 3月时序） - Bus：6.75个月 - DRAM和DMA：各约6个月 - 平台启动时间：约5.75个月

5. 结论和未来工作

本文介绍了如何复用 SystemVerilog UVM 测试台在不同抽象层次验证相同设计，并强调了混合 SystemC/SystemVerilog 仿真的收益。展示了应用 Synopsys PCIe 虚拟 I/O 解决方案时面临的问题和修复建议。提供了虚拟化 PCIe 基 SSD 系统的仿真速度、时序精度和所需启动时间。未来工作将支持通过 UVM 中 TLM-2.0 特性在事务级连接 SystemC 和 SystemVerilog 模型，无需事务-信号转换器。

6. 参考文献

[1] IEEE 1666-2011 SystemC Language Reference Manual
[2] Carbon Design Systems
[3] Synopsys SCML
[4] Accellera UVM 1.2 User's Guide, 2015

图片索引

本文共 6 张图片，存放于 SNUG_TW_Software_SiliconMotion_paper_images/ 目录。