CN114818599A - 芯片仿真验证系统 - Google Patents

Abstract

本申请涉及一种芯片仿真验证系统。该系统包括：主机侧测试模块、主机侧数据转换模块、例化对接模块、芯片侧数据转换模块和芯片侧测试模块。由于验证人员只需要实现接口转换功能，也即通过芯片侧数据转换模块和主机侧数据转换模块实现上层数据到硬件virtio协议数据的转换，从而可以避免验证人员学习了解各项目虚拟化业务，避免编写繁重的结果比对代码，避免host侧对于IO产生流程的模拟，避免对整个virtio驱动的模拟，避免像UVM架构中那样去设计rm与checker，避免重新编写繁重的代码而可能带来的错误，进而可以极大降低验证人员的工作量，实现短时间内完成验证平台的搭建，极大提高了验证效率和验证质量。

Description

芯片仿真验证系统

技术领域

本申请涉及芯片验证技术领域，特别是涉及一种芯片仿真验证系统。

背景技术

随着云计算产业的高速发展，出现了一些硬件实现virtio后端设备，如智能网卡和DPU(Data Processing Unit，数据处理器)等产品。硬件产品通常需要进行芯片验证。在相关技术中，芯片验证主要是UVM(Universal Verification Methodology，通用验证方法学)架构，这对验证人员提出了非常高的要求，不仅需要熟悉virtio协议实现的逻辑需求，还需要精通virtio前端驱动的功能，这大大增加了验证过程的工作量，降低验证效率。

发明内容

基于此，有必要针对上述技术问题，提供一种能够提要验证效率和验证质量的芯片仿真验证系统。

本申请提供了一种芯片仿真验证系统，用于对基于Virtio协议的芯片进行仿真验证，该系统包括：主机侧测试模块、主机侧数据转换模块、例化对接模块、芯片侧数据转换模块和芯片侧测试模块；

芯片侧测试模块，用于获取应用配置信息，将应用配置信息发送至芯片侧数据转换模块；芯片侧数据转换模块，用于将应用配置信息转换为芯片可识别的硬件配置信息，并将硬件配置信息发送至例化对接模块；例化对接模块，用于根据硬件配置信息对芯片进行配置和初始化；

主机侧测试模块，用于通过第一测试工具生成第一激励数据，并将第一激励数据发送至主机侧数据转换模块；主机侧数据转换模块，用于将第一激励数据转换为芯片可识别的第一测试数据，并发送至例化对接模块；例化对接模块，用于将第一测试数据发送至芯片，并将芯片基于第一测试数据进行处理后得到的第一硬件处理结果，返回至主机侧数据转换模块；主机侧数据转换模块，用于将第一硬件处理结果转换为第一测试工具可识别的第一测试结果，并返回至主机侧测试模块；主机侧测试模块，用于通过第一测试工具对第一测试结果进行校验。

在其中一个实施例中，主机侧数据转换模块包括第一寄存器适配子模块、第一以太接口适配子模块或者第一直接存储器访问子模块中的至少一种；第一寄存器适配子模块、第一以太接口适配子模块和第一直接存储器访问子模块均用于将第一测试数据发送至例化对接模块；

其中，第一寄存器适配子模块通过进程间通信与例化对接模块进行数据交互，第一以太接口适配子模块和第一直接存储器访问子模块均通过共享内存与例化对接模块进行数据交互；进程间通信包括消息队列。

在其中一个实施例中，第一测试工具为网络半虚拟化测试工具，第一激励数据为网络测试激励数据；主机侧测试模块与主机侧数据转换模块之间通过虚拟网络设备进行数据交互。

在其中一个实施例中，第一测试工具为虚拟磁盘测试工具，第一激励数据为虚拟磁盘激励数据；主机侧测试模块与主机侧数据转换模块之间通过共享文件进行数据交互。

在其中一个实施例中，主机侧测试模块，还用于在检测到数据传输错误的情况下，通过第一测试工具停止仿真验证并报错；在仿真验证完成的情况下，基于验证结果输出性能报告。

在其中一个实施例中，芯片侧测试模块，还用于通过第二测试工具生成第二激励数据，并将第二激励数据发送至芯片侧数据转换模块；芯片侧数据转换模块，还用于将第二激励数据转换为芯片可识别的第二测试数据，并发送至例化对接模块；例化对接模块，还用于将第二测试数据发送至芯片，并将芯片基于第二测试数据进行处理后得到的第二硬件处理结果，返回至芯片侧测试模块；芯片侧测试模块，还用于将第二硬件处理结果转换为第二测试工具可识别的第二测试结果，并返回至芯片侧测试模块；芯片侧测试模块，还用于通过第二测试工具对第二测试结果进行校验。

在其中一个实施例中，芯片侧数据转换模块包括第二寄存器适配子模块、第二以太接口适配子模块或者第二直接存储器访问子模块中的至少一种；第二寄存器适配子模块、第二以太接口适配子模块和第二直接存储器访问子模块均用于将第二测试数据发送至例化对接模块；

其中，第二寄存器适配子模块通过进程间通信与例化对接模块进行数据交互，第二以太接口适配子模块和第二直接存储器访问子模块均通过共享内存与例化对接模块进行数据交互；进程间通信包括消息队列。

在其中一个实施例中，第二测试工具为网络半虚拟化测试工具，第二激励数据为网络测试激励数据；芯片侧数据转换模块和芯片侧测试模块之间通过虚拟网络设备进行数据交互。

在其中一个实施例中，芯片侧测试模块，还用于启动网卡控制进程，并通过网卡控制进程生成应用配置信息。

在其中一个实施例中，芯片侧测试模块，还用于在检测到虚拟磁盘处理请求的情况下，启动虚拟磁盘处理进程，通过虚拟磁盘处理进程对虚拟磁盘处理请求进行处理；虚拟磁盘处理进程与网卡控制进程之间通过远程过程调用进行通信，远程过程调用包括Thrift进程。

上述芯片仿真验证系统，相较于传统的基于UVM架构的仿真验证平台，验证人员不需要去了解基于virtio协议的上层虚拟化业务，如host侧的各种行为，各种IO请求的产生和下发，以及用于数据交互的消息队列结构，而是可以利用测试工具实现对基于virtio协议的上层虚拟化业务的模拟，如可以模拟多host，多设备及多queue的各种数据格式报文，还可以对数据进行校验和性能分析。而验证人员只需要实现接口转换功能，也即通过芯片侧数据转换模块和主机侧数据转换模块实现上层数据到硬件virtio协议数据的转换，从而可以避免验证人员学习了解各项目虚拟化业务，避免编写繁重的结果比对代码，避免host侧对于IO产生流程的模拟，避免对整个virtio驱动的模拟，避免像UVM架构中那样去设计rm与checker，避免重新编写繁重的代码而可能带来的错误，进而可以极大降低验证人员的工作量，实现短时间内完成验证平台的搭建，极大提高了验证效率和验证质量。

另外，利用测试工具，可以多进程进行仿真，仿真速度快，检查点丰富，可以有效的将问题与缺陷暴漏在仿真阶段，从而方便代码问题的快速分析和定位。最后，由于通过上述架构可以将仿真验证与真实世界里的应用器件连接起来，从而可避免通过仿真级别的验证和加速器级别的验证需要各自设计测试用例，以实现仿真和板级测试用例的复用，进而可以降低验证人员的工作量，极大提高了验证效率和验证质量。

附图说明

图1为一个实施例中智能网卡的结构示意图；

图2为一个实施例中基于UVM实现的芯片仿真验证系统的结构示意图；

图3为一个实施例中芯片仿真验证系统的结构示意图；

图4为另一个实施例中芯片仿真验证系统的结构示意图；

图5为又一个实施例中芯片仿真验证系统的结构示意图；

图6为再一个实施例中芯片仿真验证系统的结构示意图；

图7为还一个实施例中芯片仿真验证系统的结构示意图。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

首先，对本申请实施例中涉及到的名词进行简要解释说明：

virtio协议：virtio是一种I/O半虚拟化解决方案，是一套通用I/O设备虚拟化的程序，是对半虚拟化Hypervisor中的一组通用I/O设备的抽象。它提供了一套上层应用与各Hypervisor虚拟化设备(KVM，Xen，VMware等)之间的通信框架和编程接口，减少跨平台所带来的兼容性问题，大大提高驱动程序开发效率。具体地，virtio是一个通用的半虚拟化I/O框架，Hypervisor通过它模拟出一系列的虚拟化设备。virtio框架主要包含3个部分：前端驱动(Front-end Driver)、后端设备(Back-end Device)以及Virtqueue队列。其中，前端驱动为虚拟机内部的virtio模拟设备对应的驱动(比如常见的virtio-net和virtio-blk等)，前端驱动的作用是接收用户态的请求，然后按照协议将这些请求进行封装，发送到后端设备。后端设备通常在QEMU中实现(也可以在内核中实现)，后端设备用来接收前端驱动发过来的I/O请求，然后对接收的数据进行解析，并从实际物理设备上完成收、发请求，并最终通过中断机制通知前端驱动。前端和后端的数据通过virtqueue队列进行交互，一个virtio设备可以注册若干个virtqueue队列。

集成电路验证：在流片之前，随着设计一起进行，验证的主要目的是保证芯片逻辑功能的正确性和功能的完备性。

DPU：是一种新型可编程处理器，集三个关键要素于一身。DPU是一种SOC(SystemOn Chip，系统级芯片)，它结合了行业标准的、高性能及软件可编程的多核CPU，通常基于已应用广泛的Arm架构，与其的SOC组件密切配合。另外，还结合了高性能网络接口，能以线速或网络中的可用速度解析、处理数据，并高效地将数据传输到GPU和CPU。最后，还结合了各种灵活和可编程的加速引擎，可以卸载AI、机器学习、安全、电信和存储等应用，并提升性能。

UVM：是一个以SystemVerilog类库为主体的验证平台开发框架，可以利用其可重用组件构建具有标准化层次结构和接口的功能验证环境。

host侧：指的是物理上的主机侧，对应于主体机器(host machine)。

soc侧：系统级芯片侧，对应于系统级芯片产品，如智能网卡。

testcase：测试用例。

QMEU：是一套模拟计算机的自由软件，本身并不包含或依赖KVM(Kernel-basedVirtual Machine，系统虚拟化)模块。QEMU虚拟机是纯软件实现的，可以在没有KVM模块的情况下独立运行，但是性能比较低。QEMU有整套的虚拟机实现，包括处理器虚拟化、内存虚拟化以及I/O设备的虚拟化。QEMU是一个用户空间的进程，需要通过特定的接口才能调用到KVM模块提供的功能。从QEMU角度来看，虚拟机运行期间，QEMU通过KVM模块提供的系统调用接口进行内核设置，由KVM模块负责将虚拟机置于处理器的特殊模式运行。QEMU使用了KVM模块的虚拟化功能，为自己的虚拟机提供硬件虚拟化加速以提高虚拟机的性能。

Hypervisor：又称为VMM(Virtual machine monitor，虚拟机监视器)，是用来建立与执行虚拟机器的软件、固件或硬件。被Hypervisor用来执行一个或多个虚拟机器的电脑称为主体机器(host machine)，这些虚拟机器则称为客体机器(guest machine)。Hypervisor提供虚拟的作业平台来执行客体操作系统(guest operating systems)，负责管理其他客体操作系统的执行阶段，这些客体操作系统，共同分享虚拟化后的硬件资源。

pcie(peripheral component interconnect express，外部设备互联总线)：是一种高速串行计算机扩展总线标准，属于高速串行点对点双通道高带宽传输，所连接的设备分配独享通道带宽，不共享总线带宽，主要支持主动电源管理，错误报告，端对端的可靠性传输，热插拔以及服务质量(QOS)等功能。

ddr(Double Data Rate SDRAM，双倍速率同步动态随机存储器)：一个时钟周期内传输两次数据，它能够在时钟的上升期和下降期各传输一次数据。

mac(Media Access Control，介质访问控制层)：主要是定义数据帧怎样在介质上进行传输。在共享同一个带宽的链路中，对连接介质的访问是“先来先服务”的。物理寻址在此处被定义，逻辑拓扑(信号通过物理拓扑的路径)也在此处被定义。线路控制、出错通知(不纠正)、帧的传递顺序和可选择的流量控制也在这一子层实现。

IPcore：即IP核，IP核是指用于产品应用专用集成电路或者可编辑逻辑器件的逻辑块或数据块。将一些在数字电路中常用但比较复杂的功能块，如FIR(Finite ImpulseResponse，有限长单位冲激响应)滤波器，SDRAM(Synchronous Dynamic Random-AccessMemory，同步动态随机存取内存)控制器和PCI(Peripheral Component Interconnect，外设部件互连标准)接口等等设计成可修改参数的模块，让其他用户可以直接调用这些模块，这样就大大减轻了验证人员的负担，避免重复劳动。随着CPLD/FPGA的规模越来越大，设计越来越复杂，使用IP核是一个发展趋势。

checker：UVM架构中用于肩负模拟设计行为和功能检查任务的验证组件，该验证组件可以缓存从各个monitor验证组件收集到的数据；可将被测器件dut输入接口侧的数据汇集给内置的rm；还可以通过数据比较的方法，检查实际收集到的dut输出端接口数据是否同reference model产生的期望数据一致。

基于上述名词解释，以Virtio协议芯片的产品形式为智能网卡为例，如图1所示为一种基于virtio协议实现的一款智能网卡，设计主要分为两部分：host侧逻辑和soc侧逻辑。host侧主要实现标准的virtio协议，soc侧功能主要实现一些网卡的控制逻辑和标准virtionet协议的逻辑。其中，pcie、ddr、mac均采用IPcore实现。为提高仿真速度，通常会有一个系统顶层包含上述几种功能块进行全功能系统级测试。为对智能网卡进行仿真验证，需要为图1中IPcore模块提供仿真验证框架，以形成仿真验证系统。

由此，在相关技术中，提供了一种基于UVM实现的仿真验证框架，该仿真验证框架对应的仿真验证系统可参考图2。在图2中，tb_vseq模块主要用于激励的产生，会根据测试用例testcases产生不同的seq请求，模拟host侧或者soc侧的上层IO请求的产生和下发。vseqr模块将不同的激励数据分发至各自的agent模块，各agent模块有不同的作用，如对于reg模块下的agent模块，其中driver模块用于寄存器数据的发送，由平台发送给dut，monitor模块则用于寄存器数据采集，将数据上送至rm模块。

对于dma或者ddr的agent模块，它们下的driver模块会根据dut发送过来的读写请求，产生不同的响应，它们的monitor模块则会根据请求信号将数据采集上送。rm模块作为参考模型，用来实现智能网卡的功能。scb模块用于校验，scb模块放在rm模块里实现，发送给dut的数据和接收dut返回的数据都经过rm模块的处理并上送scb模块，以进行校验对比，从而验证整个设计的正确性。

上述提及的具体工作流程为：在tb_testcase类中例化测试用例，vseqr模块根据不同的测试用例将激励数据输送到各agent模块中，然后通过各driver模块将不同的激励数据发送给dut，同时各monitor模块也会收集接口interface上的数据，上送rm模块，经处理后发往scoreboard，以进行校验对比。其中，对于网卡的输出，会有专门用于接收网卡输出结果的monitor模块，同样将输出结果送往scoreboard，以进行结果的比对。

由于上述仿真验证系统均是基于UVM架构搭建的，从而验证人员在基于UVM架构进行验证时，模拟整个host侧或者soc侧的cpu行为是非常困难的。主要是因为需要验证人员非常了解上层的虚拟化业务，例如，在模拟host或者soc侧的cpu时，需要对vm、devicegroup、virtio-blk、virtio-net和virtio-crypto等设备的分配和使用原则十分了解(如需要了解上述设备被分配为主网卡、弹性网卡和blk设备时的分配原则)，还需要了解各种IO请求的产生和下发。另外，还需要了解各设备下的各种队列queue的结构。例如，需要了解virtio-net的tx queue、rx queue和control queue等。除此之外，每种queue还支持多种包结构，同时支持多queue，多设备，多device group，多vm以及多host，上述不同组合均需要验证人员去了解。由此，会消耗验证人员大量时间去学习host侧的各种行为。如果仿真人员理解有误，且开发人员也理解错误，将bug遗漏出去，会造成巨大的风险。验证人员在了解完需求后，还需要将其转化成代码，还需要注重代码的简洁性，避免繁重的代码使仿真效率低下，从而也会加大验证人员的工作量。

再者，由于验证过程需要模拟驱动的行为，而目前也没有专门虚拟化协议文档说明驱动代码结构，从而需要花费大量时间去学习理解驱动代码，进而造成验证效率低下，还会存在理解错误的风险。除此之外，由于UVM不兼容驱动代码，导致现有的virtio驱动不能充分的利用，验证人员需要单独写代码模拟virtio驱动，且需要对写的virtio驱动代码进行调试，从而整体效率低。与此同时，未调试出的代码bug也可能遗留至下一级代码。

另外，芯片的验证除了仿真级别的验证还需要加速器级别的验证(对应不同的验证方法)，对于智能网卡这种基于virtio协议的复杂芯片而言，需要数以千计甚至万级别的用例去覆盖验证。目前通常会为仿真级别的验证设计一组验证用例，也会为加速器级别的验证设计一组验证用例，各设计一组验证用例会造成巨大的工作量。

最后，UVM架构中的比较器checker和用于模拟硬件功能的rm(reference model，参考模型)实现较为繁琐。其中，rm要模拟实现整个virtio协议，这就需要验证人员熟悉整个虚拟化协议，对于初次接触的验证人员来说，需要花费大量时间进行协议的学习，同时还要花费大量时间在设计checker上。若需求理解不到位，有可能遗漏bug到后面的测试流程，导致效率非常低。

基于上述名词解释和相关技术中提出的技术问题，在一个实施例中，提供了一种芯片仿真验证系统。如图3所示，图3主要是对该系统框架进行功能划分的简图。该系统可以对基于Virtio协议的芯片进行仿真验证。其中，该系统所适用的芯片可以为智能网卡，也可以为其它硬件产品，本申请实施例对此不作具体限定。为了便于说明，本申请实施例在解释说明时以芯片为智能网卡进行说明。该系统包括：主机侧测试模块301、主机侧数据转换模块302、例化对接模块303、芯片侧数据转换模块304和芯片侧测试模块305。

芯片侧测试模块305，用于获取应用配置信息，将应用配置信息发送至芯片侧数据转换模块304；芯片侧数据转换模块304，用于将应用配置信息转换为芯片可识别的硬件配置信息，并将硬件配置信息发送至例化对接模块303；例化对接模块303，用于根据硬件配置信息对芯片进行配置和初始化；

主机侧测试模块301，用于通过第一测试工具生成第一激励数据，并将第一激励数据发送至主机侧数据转换模块302；主机侧数据转换模块302，用于将第一激励数据转换为芯片可识别的第一测试数据，并发送至例化对接模块303；例化对接模块303，用于将第一测试数据发送至芯片，并将芯片基于第一测试数据进行处理后得到的第一硬件处理结果，返回至主机侧数据转换模块302；主机侧数据转换模块302，用于将第一硬件处理结果转换为第一测试工具可识别的第一测试结果，并返回至主机侧测试模块301；主机侧测试模块301，用于通过第一测试工具对第一测试结果进行校验。

其中，应用配置信息主要是用于配置智能网卡的各项功能，如配置虚拟交换功能、安全功能、多队列和虚拟多网卡功能等。智能网卡作为底层硬件，需要通过芯片侧数据转换模块304和主机侧数据转换模块302将接收到的上层数据转换为基于virtio协议且逻辑可识别的底层数据。也即，通过芯片侧数据转换模块304将应用配置信息转换为智能网卡可识别的硬件配置信息。智能网卡在收到硬件配置信息后，可以基于硬件配置信息完成各种功能的配置和初始化。基于应用配置信息，不仅可以实现对智能网卡进行配置，还可以使得host侧能够检测到可用的网卡设备。

第一测试工具可以用于对磁盘性能进行测试，也可以用于对网络性能进行测试，本申请实施例不对测试工具的测试项做具体限定。根据测试项的不同，对应不同类型的激励数据。以网络性能测试为例，激励数据可以为网络数据包，而网络数据包经过智能网卡处理后，可得到用于反馈丢包率或者发包性能的硬件处理结果。在经由主机侧数据转换模块302转换为测试工具可识别的测试结果后，测试工具可以对测试结果进行校验，以校验结果是否正确。

上述实施例中，相较于传统的基于UVM架构的仿真验证平台，验证人员不需要去了解基于virtio协议的上层虚拟化业务，如host侧的各种行为，各种IO请求的产生和下发，以及用于数据交互的消息队列结构，而是可以利用测试工具实现对基于virtio协议的上层虚拟化业务的模拟，如可以模拟多host，多设备及多queue的各种数据格式报文，还可以对数据进行校验和性能分析。而验证人员只需要实现接口转换功能，也即通过芯片侧数据转换模块和主机侧数据转换模块实现上层数据到硬件virtio协议数据的转换，从而可以避免验证人员学习了解各项目虚拟化业务，避免编写繁重的结果比对代码，避免host侧对于IO产生流程的模拟，避免对整个virtio驱动的模拟，避免像UVM架构中那样去设计rm与checker，避免重新编写繁重的代码而可能带来的错误，进而可以极大降低验证人员的工作量，实现短时间内完成验证平台的搭建，极大提高了验证效率和验证质量。

另外，利用测试工具，可以多进程进行仿真，仿真速度快，检查点丰富，可以有效的将问题与缺陷暴漏在仿真阶段，从而方便代码问题的快速分析和定位。最后，由于通过上述架构可以将仿真验证与真实世界里的应用器件连接起来，从而可避免通过仿真级别的验证和加速器级别的验证需要各自设计测试用例，以实现仿真和板级测试用例的复用，进而可以降低验证人员的工作量，极大提高了验证效率和验证质量。

在一些实施例中，主机侧数据转换模块包括第一寄存器适配子模块、第一以太接口适配子模块或者第一直接存储器访问子模块中的至少一种；第一寄存器适配子模块、第一以太接口适配子模块和第一直接存储器访问子模块均用于将第一测试数据发送至例化对接模块；

其中，第一寄存器适配子模块通过进程间通信与例化对接模块进行数据交互，第一以太接口适配子模块和第一直接存储器访问子模块均通过共享内存与例化对接模块进行数据交互；进程间通信包括消息队列。

具体地，第一寄存器适配子模块reg adaptor主要是将部分第一激励数据通过寄存器通道发送至例化对接模块，寄存器通道可以基于进程间通信实现，而进程间通信进一步可以为消息队列。另外，reg adaptor内可实现寄存器通道的收发函数reg receive和regsend。第一以太接口适配子模块mac adaptor主要是将部分第一激励数据通过以太接口发送至例化对接模块，mac adaptor内可实现以太接口的收发函数mac client和mac server。第一直接存储器访问子模块dma adaptor主要是将部分第一激励数据通过直接存储器访问的方式发送至例化对接模块，dma adaptor内可实现以太接口的收发函数dma client和dmaserver。

结合上述内容，现对第一测试数据的发送过程进行说明。具体地，主机侧数据转换模块在监测到由主机侧测试模块传入的第一激励数据的数据流时，可解析该数据流，得到该数据流的类型、长度、host_id、vf_id、queue_id和五元组等信息，将其重组成智能网卡可识别的且基于virt-queue的数据结构的第一测试数据。主机侧数据转换模块将第一测试数据中的一部分测试数据放到共享内存dma mem中，由第一以太接口适配子模块和第一直接存储器访问子模块分别发送至例化对接模块，将另一部分数据通过消息队列发送至例化对接模块。

上述实施例中，由于验证人员只需要实现接口转换功能，从而可以极大降低验证人员的工作量，实现短时间内完成验证平台的搭建，极大提高了验证效率和验证质量。

在一些实施例中，第一测试工具为网络半虚拟化测试工具，第一激励数据为网络测试激励数据；主机侧测试模块与主机侧数据转换模块之间通过虚拟网络设备进行数据交互。

具体地，网络半虚拟化测试工具可以包括iperf或者net-perf，本申请实施例对此不作具体限定。其中，iperf是一个基于virtio-net的网络性能测试第三方工具，可以测试TCP和UDP带宽质量，同时也可以通过UDP测试获得网络丢包率或者发包性能。net-perf也是一种基于virtio-net的网络性能测试第三方工具，主要针对基于TCP或UDP的传输，根据应用的不同，可以进行不同模式的网络性能测试，如批量数据传输(bulk data transfer)模式和请求/应答(request/reponse)模式。

虚拟网络设备可以为tun与tap，tun与tap是操作系统内核中的虚拟网络设备。不同于普通靠硬件网络适配器实现的设备，上述虚拟网络设备全部用软件实现，并向运行于操作系统上的软件提供与硬件的网络设备完全相同的功能。

tun是网络层的虚拟网络设备，可以收发第三层数据报文包，如IP封包，从而常用于一些点对点IP隧道，例如OpenVPN，IPSec等。tap是链路层的虚拟网络设备，等同于一个以太网设备，它可以收发第二层数据报文包，如以太网数据帧。Tap最常见的用途为虚拟机的网卡，主要是因为它和普通的物理网卡更加相近，也经常用作普通机器的虚拟网卡。

上述实施例中，由于可以利用网络半虚拟化测试工具实现对基于virtio-net的上层虚拟化业务的模拟，验证人员只需要实现接口转换功能，从而可以极大降低验证人员的工作量，实现短时间内完成验证平台的搭建，极大提高了验证效率和验证质量。

在一些实施例中，第一测试工具为虚拟磁盘测试工具，第一激励数据为虚拟磁盘激励数据；主机侧测试模块与主机侧数据转换模块之间通过共享文件进行数据交互。

具体地，虚拟磁盘测试工具可以包括fio，fio是基于virtio-net的磁盘性能测试第三方工具，可以用于对硬件进行压力测试和验证。磁盘IO是检查磁盘性能的重要指标，可以按照负载情况分成按顺序读写和随机读写两大类，fio可用于测试磁盘的IOPS(Input/Output Operations Per Second，每秒进行读写操作的次数)。

上述实施例中，由于可以利用虚拟磁盘测试工具实现对基于virtio-blk的上层虚拟化业务的模拟，验证人员只需要实现接口转换功能，从而可以极大降低验证人员的工作量，实现短时间内完成验证平台的搭建，极大提高了验证效率和验证质量。

在一些实施例中，主机侧测试模块，还用于在检测到数据传输错误的情况下，通过第一测试工具停止仿真验证并报错；在仿真验证完成的情况下，基于验证结果输出性能报告。

以第一测试工具为iperf为例，iperf在接收到IO处理结果后(对应于第一硬件处理结果)，可以对IO处理结果进行校验。在检测到数据传输操作的情况下，可以不再生成激励数据，停止仿真验证，并进行报错。若仿真验证完成，可以打印输出IO性能报告。

上述实施例中，由于通过第一测试工具可以进行验证报错，且在仿真验证结束后可以输出验证性能报告，从而提高了验证质量。

在一些实施例中，芯片侧测试模块，还用于通过第二测试工具生成第二激励数据，并将第二激励数据发送至芯片侧数据转换模块；芯片侧数据转换模块，还用于将第二激励数据转换为芯片可识别的第二测试数据，并发送至例化对接模块；例化对接模块，还用于将第二测试数据发送至芯片，并将芯片基于第二测试数据进行处理后得到的第二硬件处理结果，返回至芯片侧测试模块；芯片侧测试模块，还用于将第二硬件处理结果转换为第二测试工具可识别的第二测试结果，并返回至芯片侧测试模块；芯片侧测试模块，还用于通过第二测试工具对第二测试结果进行校验。

具体地，上述实施例主要是host侧的验证，而本申请实施例主要是soc侧的验证，具体验证过程可参考上述实施例的内容，此处不再赘述。

上述实施例中，由于验证人员只需要实现接口转换功能，也即通过芯片侧数据转换模块和主机侧数据转换模块实现上层数据到硬件virtio协议数据的转换，从而可以极大降低验证人员的工作量，实现短时间内完成验证平台的搭建，极大提高了验证效率和验证质量。另外，利用测试工具，可以多进程进行仿真，仿真速度快，检查点丰富，可以有效的将问题与缺陷暴漏在仿真阶段，从而方便代码问题的快速分析和定位。最后，由于通过上述架构可以将仿真验证与真实世界里的应用器件连接起来，从而可避免通过仿真级别的验证和加速器级别的验证需要各自设计测试用例，以实现仿真和板级测试用例的复用，进而可以降低验证人员的工作量，极大提高了验证效率和验证质量。

在一些实施例中，芯片侧数据转换模块包括第二寄存器适配子模块、第二以太接口适配子模块或者第二直接存储器访问子模块中的至少一种；第二寄存器适配子模块、第二以太接口适配子模块和第二直接存储器访问子模块均用于将第二测试数据发送至例化对接模块；

其中，第二寄存器适配子模块通过进程间通信与例化对接模块进行数据交互，第二以太接口适配子模块和第二直接存储器访问子模块均通过共享内存与例化对接模块进行数据交互；进程间通信包括消息队列。

其中，关于第二寄存器适配子模块、第二以太接口适配子模块和第二直接存储器访问子模块的相关说明，可以参考上述实施例中关于第一寄存器适配子模块、第一以太接口适配子模块和第一直接存储器访问子模块的相关说明，此处不再赘述。

上述实施例中，由于验证人员只需要实现接口转换功能，从而可以极大降低验证人员的工作量，实现短时间内完成验证平台的搭建，极大提高了验证效率和验证质量。

在一些实施例中，第二测试工具为网络半虚拟化测试工具，第二激励数据为网络测试激励数据；芯片侧数据转换模块和芯片侧测试模块之间通过虚拟网络设备进行数据交互。

其中，第二测试工具也可以具体为iperf或者net-perf，相关说明可参考上述实施例的内容，此处不再赘述。

上述实施例中，由于可以利用网络半虚拟化测试工具实现对基于virtio-net的上层虚拟化业务的模拟，验证人员只需要实现接口转换功能，从而可以极大降低验证人员的工作量，实现短时间内完成验证平台的搭建，极大提高了验证效率和验证质量。

在一些实施例中，芯片侧测试模块，还用于启动网卡控制进程，并通过网卡控制进程生成应用配置信息。

上述实施例中，由于可以通过网卡控制程序配置智能网卡，从而可以为验证人员提供便捷接口，提高验证效率。

在一些实施例中，芯片侧测试模块，还用于在检测到虚拟磁盘处理请求的情况下，启动虚拟磁盘处理进程，通过虚拟磁盘处理进程对虚拟磁盘处理请求进行处理；虚拟磁盘处理进程与网卡控制进程之间通过远程过程调用进行通信，远程过程调用包括Thrift进程。

其中，虚拟磁盘处理进程可以通过vtgt进程进行表示。vtgt进程可以处于等待状态，直至接收到虚拟磁盘处理请求，则芯片侧测试模块可虚拟磁盘处理进程。虚拟磁盘处理请求通常是请求处理比较大的文件，虚拟磁盘处理进程可将虚拟磁盘处理请求所请求处理的文件分成基于virtio-net的网络数据，再通过虚拟网络传至相应磁盘进行存储。

上述实施例中，由于可以利用虚拟磁盘测试工具实现对基于virtio-blk的上层虚拟化业务的模拟，验证人员只需要实现接口转换功能，从而可以极大降低验证人员的工作量，实现短时间内完成验证平台的搭建，极大提高了验证效率和验证质量。

为了便于理解，以上述五个模块，主机侧测试模块、主机侧数据转换模块、例化对接模块、芯片侧数据转换模块和芯片侧测试模块分别用host_test_program、host_wrapper、tb_top、soc_wrapper以及soc_test_program进行表示为例，现结合实际情况，对上述五个模块进行详细说明。

其中，host_test_program与host_wrapper之间结构及连接示意图可参考图4。host_wrapper与tb_top之间结构及连接示意图可参考图5。tb_top与soc_wrapper之间结构及连接示意图可参考图6。soc_wrapper与soc_test_program之间结构及连接示意图可参考图7。图3至图7中弧形箭头代表进程。

在图4中，host_test_program可实现host激励数据的产生和结果的校验，以及性能的分析。FIO即为虚拟磁盘测试工具，iperf与net-perf均为网络半虚拟化测试工具。host_test_program与host_wrapper之间通过共享文件进行虚拟磁盘相关的数据交互。通过tun/tap虚拟网络设备模拟的网卡(virtio-net)，host_test_program与host_wrapper之间可网络相关的数据交互。

host_wrapper可实现数据转换，主要是将测试工具产生的数据转换为智能网卡可识别的且基于virtio硬件数据格式的数据，并发送给tb_top。其中，reg通道基于进程间通信的消息队列reg fifo实现，在host_wrapper内部有reg adaptor，里面实现了reg send和reg recieve函数以用于寄存器通道数据的交互。dma和mac数据通道基于共享内存实现，dma数据对应的共享内存为dma mem，而mac数据对应的共享内存为mac0 mem和mac1 mem。host_wrapper内部实现dma adaptor和mac adaptor，内部分别实现了dma的server、dma的client、mac的server以及mac的client，最终实现dma和mac数据的传递。其中，host_wrapper内部根据需求还可以实现比较器checker。

在图5中，tb_top负责将收到的reg接口、dma接口或者mac接口数据发送给智能网卡。同时，将智能网卡的输出返回至host wrapper或者soc wrapper。tb_top内部例化了智能网卡，实现了reg通道的reg send和reg recieve函数、还实现了dma的server和client，以及mac的server和client。

在图6中，关于soc_wrapper的说明可参考上述关于host_wrapper的相关说明。同样地，soc_wrapper内部根据需求还可以实现比较器checker。

在图7中，soc_test_program主要包括三个程序，一个为智能网卡的控制程序，一个为vtgt程序。该两个程序对应的进程之间基于thrift进程进行数据交互。soc_test_program还包括第三个程序，即为测试程序。soc侧可仅运行一些标准的virtio net测试程序，如net-perf和iperf。同样地，soc test program可通过tun/tap虚拟网络设备模拟的网卡(virtio-net)进行激励数据的发送。

本领域技术人员可以理解，图3至图7中示出的结构，仅仅是与本申请方案相关的部分结构的框图，并不构成对本申请方案所应用于其上的芯片仿真验证系统的限定，具体的芯片仿真验证系统可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。

为了便于理解，结合上述芯片仿真验证系统的结构，现以virtio-net的测试流程为例，对该芯片仿真验证系统的运行过程进行举例说明：

(1)启动soc_test_program里面的网卡控制程序和vtgt程序，分两个进程启动，该两个进程间通过thift进行数据交互。网卡控制程序主要配置智能网卡的各项功能，保证host侧可检测到可用网卡，此为启动第一个进程。vtgt程序则等待，如果有blk相关的请求上送过来，则处理，此为启动第二个进程；

(2)启动soc_wrapper和tb_top两个进程，soc_wrapper主要实现接口的转换，用以将配置信息通过寄存器通道下发至tb_top，完成tb_top各种规格的配置和初始化，此为第三个和第四个进程。

(3)启动host_test_program进程，该进程会启动测试用例。具体过程为启动iperf测试软件，配置发送报文大小个数等信息，发送报文，并等待智能网卡的处理结果，此为第五个进程。

(4)启动host_wrapper进程，当监测到host_test_program有数据输入，解析该数据流，得到数据的类型、长度、host_id、vf_id、queue_id、五元组等必要信息，将其重组成智能网卡能识别的且基于virt-queue数据结构的测试数据，将测试数据存放到共享内存中，通过共享内存和reg消息队列将测试数据发送至tb_top，触发智能网卡开始数据处理，此为第六个进程。

(5)tb_top进程监测到有测试数据的处理请求，会由智能网卡处理请求，得到处理结果。其中，如果有需要可以送到soc侧进行处理，然后再返回智能网卡，得到处理结果。将处理结果通过共享内存返回至host_wrapper，host_wrapper可检测到数据上送，host_wrapper将数据处理完后会发送至host_test_program。host_test_program中的iperf收到后会对IO进行内容校验，如果数据传输错误会报错停止仿真，最终所有IO都处理完还可以打印性能报告。此时，一个基本的virtio-net测试流程完成。

本领域普通技术人员可以理解实现上述实施例运行过程中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述运行过程的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(Read-Only Memory，ROM)、磁带、软盘、闪存、光存储器、高密度嵌入式非易失性存储器、阻变存储器(ReRAM)、磁变存储器(Magnetoresistive Random Access Memory，MRAM)、铁电存储器(Ferroelectric Random Access Memory，FRAM)、相变存储器(Phase Change Memory，PCM)、石墨烯存储器等。易失性存储器可包括随机存取存储器(Random Access Memory，RAM)或外部高速缓冲存储器等。作为说明而非局限，RAM可以是多种形式，比如静态随机存取存储器(Static Random Access Memory，SRAM)或动态随机存取存储器(Dynamic RandomAccess Memory，DRAM)等。本申请所提供的各实施例中所涉及的数据库可包括关系型数据库和非关系型数据库中至少一种。非关系型数据库可包括基于区块链的分布式数据库等，不限于此。本申请所提供的各实施例中所涉及的处理器可为通用处理器、中央处理器、图形处理器、数字信号处理器、可编程逻辑器、基于量子计算的数据处理逻辑器等，不限于此。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请的保护范围应以所附权利要求为准。

Claims (10)

1.一种芯片仿真验证系统，其特征在于，所述系统包括：主机侧测试模块、主机侧数据转换模块、例化对接模块、芯片侧数据转换模块和芯片侧测试模块；

所述芯片侧测试模块，用于获取应用配置信息，将所述应用配置信息发送至所述芯片侧数据转换模块；所述芯片侧数据转换模块，用于将所述应用配置信息转换为所述芯片可识别的硬件配置信息，并将所述硬件配置信息发送至所述例化对接模块；所述例化对接模块，用于根据所述硬件配置信息对所述芯片进行配置和初始化；

所述主机侧测试模块，用于通过第一测试工具生成第一激励数据，并将所述第一激励数据发送至所述主机侧数据转换模块；所述主机侧数据转换模块，用于将所述第一激励数据转换为所述芯片可识别的第一测试数据，并发送至例化对接模块；所述例化对接模块，用于将所述第一测试数据发送至所述芯片，并将所述芯片基于所述第一测试数据进行处理后得到的第一硬件处理结果，返回至所述主机侧数据转换模块；所述主机侧数据转换模块，用于将所述第一硬件处理结果转换为所述第一测试工具可识别的第一测试结果，并返回至所述主机侧测试模块；所述主机侧测试模块，用于通过所述第一测试工具对所述第一测试结果进行校验。

2.根据权利要求1所述的系统，其特征在于，所述主机侧数据转换模块包括第一寄存器适配子模块、第一以太接口适配子模块或者第一直接存储器访问子模块中的至少一种；所述第一寄存器适配子模块、所述第一以太接口适配子模块和所述第一直接存储器访问子模块均用于将所述第一测试数据发送至所述例化对接模块；

其中，所述第一寄存器适配子模块通过进程间通信与所述例化对接模块进行数据交互，所述第一以太接口适配子模块和所述第一直接存储器访问子模块均通过共享内存与所述例化对接模块进行数据交互；所述进程间通信包括消息队列。

3.根据权利要求2所述的系统，其特征在于，所述第一测试工具为网络半虚拟化测试工具，所述第一激励数据为网络测试激励数据；所述主机侧测试模块与所述主机侧数据转换模块之间通过虚拟网络设备进行数据交互。

4.根据权利要求2所述的系统，其特征在于，所述第一测试工具为虚拟磁盘测试工具，所述第一激励数据为虚拟磁盘激励数据；所述主机侧测试模块与所述主机侧数据转换模块之间通过共享文件进行数据交互。

5.根据权利要求1所述的系统，其特征在于，所述主机侧测试模块，还用于在检测到数据传输错误的情况下，通过所述第一测试工具停止仿真验证并报错；在仿真验证完成的情况下，基于验证结果输出性能报告。

6.根据权利要求1所述的系统，其特征在于，所述芯片侧测试模块，还用于通过第二测试工具生成第二激励数据，并将所述第二激励数据发送至所述芯片侧数据转换模块；所述芯片侧数据转换模块，还用于将所述第二激励数据转换为所述芯片可识别的第二测试数据，并发送至例化对接模块；所述例化对接模块，还用于将所述第二测试数据发送至所述芯片，并将所述芯片基于所述第二测试数据进行处理后得到的第二硬件处理结果，返回至所述芯片侧测试模块；所述芯片侧测试模块，还用于将所述第二硬件处理结果转换为所述第二测试工具可识别的第二测试结果，并返回至所述芯片侧测试模块；所述芯片侧测试模块，还用于通过所述第二测试工具对所述第二测试结果进行校验。

7.根据权利要求6所述的系统，其特征在于，所述芯片侧数据转换模块包括第二寄存器适配子模块、第二以太接口适配子模块或者第二直接存储器访问子模块中的至少一种；所述第二寄存器适配子模块、所述第二以太接口适配子模块和所述第二直接存储器访问子模块均用于将所述第二测试数据发送至所述例化对接模块；

其中，所述第二寄存器适配子模块通过进程间通信与所述例化对接模块进行数据交互，所述第二以太接口适配子模块和所述第二直接存储器访问子模块均通过共享内存与所述例化对接模块进行数据交互；所述进程间通信包括消息队列。

8.根据权利要求7所述的系统，其特征在于，所述第二测试工具为网络半虚拟化测试工具，所述第二激励数据为网络测试激励数据；所述芯片侧数据转换模块和所述芯片侧测试模块之间通过虚拟网络设备进行数据交互。

9.根据权利要求1所述的系统，其特征在于，所述芯片侧测试模块，还用于启动网卡控制进程，并通过所述网卡控制进程生成所述应用配置信息。

10.根据权利要求9所述的系统，其特征在于，所述芯片侧测试模块，还用于在检测到虚拟磁盘处理请求的情况下，启动虚拟磁盘处理进程，通过所述虚拟磁盘处理进程对所述虚拟磁盘处理请求进行处理；所述虚拟磁盘处理进程与所述网卡控制进程之间通过远程过程调用进行通信，所述远程过程调用包括Thrift进程。

Images