CN117762771A - 一种验证平台搭建方法、电子设备及存储介质 - Google Patents

Abstract

本发明实施例涉及物联网技术领域，公开了一种验证平台搭建方法、电子设备及存储介质。本发明中，首先获取了第一待测试模块，根据所述第一待测试模块的类型获取对应的设计文档，根据所述设计文档搭建第一验证平台；若第一待测试模块的类型与第二待测试的类型不同，则获取第一验证平台中的共用信息；获取第二设计文档，根据所述第二设计文档和所述共用信息搭建所述第二验证平台。通过根据不同的模块类型搭建平台，若需要验证的测试模块类型不同，在整个项目验证的各个阶段，都不需要大的改动，只需微调即可。IP级的测试用例在系统级平台上可以复用，保证了验证中整个通路上的各模块融合无误，不存在模块之间的冲突。

Description

一种验证平台搭建方法、电子设备及存储介质

技术领域

本发明实施例涉及物联网技术领域，特别涉及一种验证平台搭建方法、电子设备及存储介质。

背景技术

随着5G通信技术和时代的发展，万物互联的智能化需求成为时代的主旋律，实现万物互联最关键的是NB-IOT芯片。在不久的未来，千亿级的需求对芯片的质量提出了更高的要求，电池寿命长达十年，如此大的量，至少十年的使用周期，都要表现优秀，任何极限状态下的错误都是不可想象的，也是不可接受的。如何保证每个模块在任何条件下都不出错，成为迫切的需求，整个系统所有模块完美的协作配合同样重要。

传统的模块验证是每个工程师自己开发验证环境，自己加激励，验证模块的主要功能，很多情况下是设计人员自己验证，多数对UVM系统不熟悉，就用Verilog加激励，通过波形观察输出结果或简单的数据比较。最后检查完代码覆盖率，状态机覆盖率，触发覆盖率就结束了。功能覆盖率是最难界定的，怎么样才算所有功能都覆盖，有没有极限情况，在极端情况下是否会出现异常，包括很多验证工程师在内都不好判断。

发明人发现相关技术中至少存在如下问题：(1)每个工程师的技术水平差异巨大，无法保证每个人的验证都达到同样的水平。(2)对NB-IOT系统来说，每个模块的通用接口有的是AHB接口，有的是APB接口，无法保证验证达到同样的水平。(3)无法保证验证整个通路上的各模块融合无误，模块之间容易产生冲突。

发明内容

本发明实施方式的目的在于提供一种验证平台搭建方法、电子设备及存储介质，使得不论是什么技术水平的工程师，模块的使用什么接口，验证都达到同样的水平，同时保证了验证中整个通路上的各模块融合无误，不存在模块之间的冲突。

为解决上述技术问题，本发明的实施方式提供了一种验证平台搭建方法，包括：获取第一待测试模块，并检测所述第一待测试模块的类型；根据所述第一待测试模块的类型获取对应的第一设计文档，根据所述第一设计文档搭建第一验证平台；所述第一验证平台用于对所述第一待测试模块进行测试；获取第二待测试模块，并检测所述第二待测试模块的类型；若所述第一待测试模块的类型与所述第二待测试的类型不同，则获取第一验证平台中的共用信息；获取第二设计文档，根据所述第二设计文档和所述共用信息搭建所述第二验证平台。

本发明的实施方式还提供了一种电子设备，包括：至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行上述的验证平台搭建方法。

本发明的实施方式还提供了一种计算机可读存储介质，存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现上述的验证平台搭建方法。

在本发明实施方式中，首先获取了第一待测试模块，并检测所述第一待测试模块的类型；根据所述第一待测试模块的类型获取对应的第一设计文档，根据所述第一设计文档搭建第一验证平台；所述第一验证平台用于对所述第一待测试模块进行测试；获取第二待测试模块，并检测所述第二待测试模块的类型；若所述第一待测试模块的类型与所述第二待测试的类型不同，则获取第一验证平台中的共用信息；获取第二设计文档，根据所述第二设计文档和所述共用信息搭建所述第二验证平台。通过根据不同的模块类型搭建平台，再根据对应的设计文档构建用于测试的验证平台，若需要验证的测试模块类型不同，在整个项目验证的各个阶段，都不需要大的改动，只需微调即可。IP级的测试用例在系统级平台上可以复用，保证了不论是什么技术水平的工程师，模块的使用什么接口，验证都达到同样的水平，同时保证了验证中整个通路上的各模块融合无误，不存在模块之间的冲突。

另外，所述根据所述第一设计文档搭建第一验证平台，包括：根据所述第一设计文档，依次开发所述第一待测试模块的UVC、所述第一待测试模块所需的第一测试序列和所述第一待测试模块的顶层模块，通过开发后的所述第一待测试模块的UVC、所述第一待测试模块所需的测试序列和所述第一待测试模块的顶层模块搭建所述第一验证平台。使得任何新开发的子模块都可以实现快速搭建平台，快速完成验证。

另外，所述获取第一验证平台中的共用信息，包括：获取所述第一验证平台中所述开发后的所述第一待测试模块的顶层模块；所述第一待测试模块的顶层模块用于开发所述第二待测试模块中的顶层模块。顶层模块可以直接使用，无需做出改变，大大减少了开发周期，降低了出错的机会，验证效率明显提高。

另外，所述第一验证平台和所述第二验证平台均包括以下之一或其任意组合：AHBMaster模型、AHB Slave模型，APB Master模型、APB Slave模型。平台设计了AHB Master模型和Slave模型，APB Master模型和Slave模型，考虑到各种竞争场景的覆盖，可以处理各种极端复杂场景下的验证。

另外，所述开发所述第一待测试模块的UVC，包括：根据所述第一设计文档所记载的指令获取第一寄存器的列表并检测所述第一待测试模块的功能模式，并根据所述第一寄存器的列表和所述第一待测试模块的功能模式对所述第一寄存器分配不同的值；其中，所述第一待测试模块的功能模式至少包括：正常工作模式，浅睡眠模式和深睡模式。根据模块修改顶层DUT接口和测试用例中自己模块的控制信息，提升模块运行的健壮性。

另外，所述方法还包括：所述开发第一待测试模块所需的第一测试序列后，对所述第一测试序列进行参数例化操作。

另外，所述方法还包括：所述开发所述第一待测试模块的顶层模块后，还包括：创建用于测试所述第一待测试模块的相关路径或文件列表；所述获取第一验证平台中的共用信息后，还包括：创建用于测试所述第二待测试模块的相关路径或文件列表。

另外，所述根据所述第二设计文档和所述共用信息搭建所述第二验证平台，包括：根据所述第二设计文档，依次开发所述第二待测试模块的UVC、所述第二待测试模块所需的第二测试序列；通过开发后的所述第二待测试模块的UVC、所述第二待测试模块所需的测试序列和所述第二待测试模块的顶层模块搭建所述第二验证平台。

附图说明

一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定，附图中具有相同参考数字标号的元件表示为类似的元件，除非有特别申明，附图中的图不构成比例限制。

图1是根据本发明的一实施方式中提供的验证平台搭建方法流程图；

图2是根据本发明的一实施方式中提供的带总线的模型结构示意图；

图3是根据本发明的一实施方式中提供的验证平台结构示意图；

图4是根据本发明的一实施方式中提供的BURST之间的延迟的变化的示意图；

图5是根据本发明的一实施方式中提供的模型直接连接的结构示意图；

图6是根据本发明的一实施方式中提供的写操作演变成多种写事务的示意图；

图7是根据本发明的一实施方式中提供的读操作演变成多种读事务的示意图；

图8是根据本发明的一实施方式中提供的多TASK的相互配合的示意图；

图9是根据本发明的另一实施方式提供的电子设备的结构示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合附图对本发明的各实施方式进行详细的阐述。然而，本领域的普通技术人员可以理解，在本发明各实施方式中，为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施方式的种种变化和修改，也可以实现本申请所要求保护的技术方案。以下各个实施例的划分是为了描述方便，不应对本发明的具体实现方式构成任何限定，各个实施例在不矛盾的前提下可以相互结合相互引用。

本发明的一实施方式涉及一种验证平台搭建方法，可以应用在如手机，电脑等终端设备。在本实施方式中，获取第一待测试模块，并检测所述第一待测试模块的类型；根据所述第一待测试模块的类型获取对应的第一设计文档，根据所述第一设计文档搭建第一验证平台；所述第一验证平台用于对所述第一待测试模块进行测试；获取第二待测试模块，并检测所述第二待测试模块的类型；若所述第一待测试模块的类型与所述第二待测试的类型不同，则获取第一验证平台中的共用信息；获取第二设计文档，根据所述第二设计文档和所述共用信息搭建所述第二验证平台，通过根据不同的模块类型搭建平台，再根据对应的设计文档构建用于测试的验证平台，若需要验证的测试模块类型不同，在整个项目验证的各个阶段，都不需要大的改动，只需微调即可。IP级的测试用例在系统级平台上可以复用，保证了不论是什么技术水平的工程师，模块的使用什么接口，验证都达到同样的水平，同时保证了验证中整个通路上的各模块融合无误，不存在模块之间的冲突。下面对本实施方式的验证平台搭建方法的实现细节进行具体的说明，以下内容仅为方便理解提供的实现细节，并非实施本方案的必须。

如图1所示，在步骤101中，获取第一待测试模块，并检测所述第一待测试模块的类型。由于本申请复用性较广，每个不同类型的模块有着不同的测试平台、测试用例、测试环境，因此获取待测试模块的类型就尤为重要。以便在步骤102中，获取对应的第一设计文档，根据所述第一设计文档搭建第一验证平台；所述第一验证平台用于对所述第一待测试模块进行测试。

任何NB-IOT的各个子模块均包括以下部分：CPU主和从模型，处理器UVC，时钟UVC，复位UVC，测试序列库，顶层结构，第三方VIP(VIP：Verification IP，验证环境的知识产权模块)的UVC，寄存器模型，断言检查，覆盖率统计，存储器验证，测试用例。以下将依次论述其作用：

CPU主和从模型，包括AHB(AHB:Advanced High Performance Bus先进的高性能总线)主模型和从模型，APB(APB:Advanced Peripheral Bus先进的外围总线)主模型和从模型，内嵌各种专有目的任务，比如CPU读写时间隔时间从零个到N个时钟周期可以遍历，SLAVE响应时间从零个到N个时钟周期可以遍历，响应类型的选择，可以控制回复错误状态或正常状态等，每种任务都有自己的特点，比如连续读操作间隔可调，连续写操作间隔可调，连续写操作和读操作间隔可调，同种BURST类型的连续操作，每次各种随机类型的连续操作，需要指定输入数据的读写操作，随机数据的读写操作，带自动比对的操作和不带自动比对的操作等。

下文中的UVC的全称是UVM component，简称UVC，(UVM：Universal VerificationMethodology,通用验证方法学、UVC：UVM component,验证组件)往往是我们构建环境中所用到的最底层的组件，它虽然“小”，但却十分重要，许多模块级的验证甚至SOC验证都会使用相同的UVC，牵一发而动全身。而VIP的范围就更广了，多为第三方提供(也有企业自研VIP)，它可能不仅仅只是一个uvm的组件，可能会是一个纯sv的对象集合，也可能会是一些verilog的model，所以uvc是vip的一个非空真子集。下文将不再做过多重复介绍。

处理器UVC，包括Adapter文件(adapter：适配器),Agent文件,Define文件，Driver文件，接口文件，Sequencer文件，Transaction文件，Reg_access_sequence文件，其中Driver文件会根据需要的操作种类去调度CPU模型中对应的任务，Transaction文件负责对CPU总线上所有的信号做出合理的约束。Adapter文件和Reg_access_sequence文件负责寄存器模型的连接。

时钟UVC，负责提供系统需要的各种时钟，周期和占空比可调。

复位UVC，负责提供系统需要的各种复位操作，比如同步复位，异步复位，起始信号的状态，复位的时刻等。

所述测试序列库，包括两层，上层是系统总库，包括每个子模块的测试序列库和一些基本的例化。在每个子模块的库文件中，有总线操作的各种类，比如支持不同位宽的读写，不同处理器的读写，模块功能的测试序列类，时钟类，复位类等。

顶层结构，包括第三方VIP的BUS3用于DUT(DUT:Design under test待测设计)数据接口上的总线行为规范的检测，模型的MASTER(MASTER:主模块)接VIP的BUS1的MASTER口，DUT的SLAVE(SLAVE:从模块)口和VIP的BUS1的SLAVE相接，DUT的MASTER口接总线BUS2的MASTER口，模型的SLAVE接口接BUS2的SLAVE口，BUS1和BUS2的MASTER和SLAVE模型均有多个，用来测试多核竞争场景。在没有第三方VIP的情况下，模型可以的DUT直接连接，模型自身除了数据比对外，还进行协议规则检查。

第三方VIP的UVC，需要修改对应的文件，特别是模型替换的部分，在环境顶层需要把对应的SVE做例化，使得现有系统可以识别到这些VIP。

寄存器模型，支持32位或8位地址访问方式，既可以前门和后门读写所有可访问的寄存器，也包括所有的存储器单元。采用PYTHON脚本把EXCEL表的寄存器表单转成寄存器模型文件，每个模块是一个部分，可以多个模块在一个文件，都可以前后门访问。访问存储器时，可以用各种已知的封装好的类。

断言检查，包括基本的功能点的检查，时钟源切换时的毛刺检查，复位功能的检查等。

覆盖率统计，既有传统的代码覆盖率，状态机覆盖率，触发覆盖率和表达式覆盖率等，也有功能点的统计，功能点的交叉覆盖等。

存储器验证，主要是通过存储器的控制器访问外部的存储器单元，在测试中通过预先后门放入一批数据，然后启动总线读操作，读完后，和预先放入的数据做比对。如果是写操作，启动总线写入一批数据，通过后门访问的方式抓取存储空间的数据，做比对。

测试用例，根据功能点的不同，调度相应的测试序列库，对相应的参数做出约束。

在一个例子中，根据所述第一设计文档搭建第一验证平台，包括：根据所述第一设计文档，依次开发所述第一待测试模块的UVC、所述第一待测试模块所需的第一测试序列和所述第一待测试模块的顶层模块，通过开发后的所述第一待测试模块的UVC、所述第一待测试模块所需的测试序列和所述第一待测试模块的顶层模块搭建所述第一验证平台。

搭建的面向NB-IOT类IP的验证平台框架图如图2所示，平台的结构框图如图3所示，其中，ROOT:根目录；SIM：simulation,仿真运行目录；CHIP：RTL和验证环境文件列表目录；TB：testbench目录；RTL：设计文件目录；SCRIPTS：脚本文件目录；UVM_TESTS:测试用例目录；BOARD：模块文或芯片验证平台顶层文件；CHIP_ENV：验证环境目录；C_MODEL：C文件目录，例如算法文件；ip_testcase_top.sv:包含各个子模块测试用例列表文件；lcd_u:LCD模块测试用例目录；dfe_u:DFE模块测试用例目录；bb_u:BB模块测试用例目录；ip_base_test.sv:包含顶层文件的例化和统计信息；ip_env.sv:验证组件的连接；ip_env_def.svh:验证环境中常用路径的宏定义；ip_env_top.sv:每个模块的验证环境相关文件的列表；ip_env_common.sv:对UVM常用打印信息做宏定义，代码更简洁；ip_vsqr.sv:virtualsequencer,虚拟序列发生器，模块的序列发生器例化在这里，错误统计信息；ip_test_def.svh:测试用例中例化的宏定义；dfe_u目录下，ip_dfe_testcase_top.sv:DFE模块的测试用例列表；ip_dfe_a.sv:测试用例a,ip_dfe_b.sv:测试用例b；seq_lib目录下，ip_env_seq_def.svh:测试用例中序列部分声明的宏定义，常用序列的宏定义；ip_env_seq_lib.sv:包含各个模块的库文件；ip_prcm_seq_lib.sv:PRCM模块的测试序列库；ip_prcm_seq_def.svh:PRCM模块序列相关的宏定义；ip_dfe_seq_lib.sv:DFE模块的测试序列库。

设计文档中有属性列表，测试用例和序列的详细步骤，可以用于开发各个模块。

在一个例子中，通过以下方式验证环境顶层文件的处理以达到开发顶层模块的目的：

下文的顶层文件是顶层模块中的文件，文件名均为本领域技术人员可以理解的标准的文件名称，将详细介绍在这些文件中做出的具体调节。

·在ip_vsqr.sv中，声明时钟，复位和CPU的sequencer，CPU寄存器模型的例化。各个IP的sequencer例化。例如在AMBA模块(AMBA：Advanced MicrocontrollerBusArchitecture高级微处理器总线架构)中，例化了Apb*Sve,Ahb*Sve和axi4*Sve.然后进行创建。

·在ip_env_def.svh中，包括顶层一些模型路径的宏定义。

·在ip_test_def.svh中，对测试用例的公用部分进行宏定义。例如`defineIP_TEST_BEGIN(mname,sname).mname代表模块名，sname代表测试用例的名称。

·在ip_env_common.sv，做系统常用打印信息的宏定义，简化书写信息。

·在ip_env_top.sv,include所有相关的验证文件，如果有VIP的也在这里。

·在ip_env.sv,是一些通用AGENT的例化，包括时钟，复位，寄存器模型等。

·在ip_base_test.sv,是env,vsqr,reg_model,adapter例化。寄存器模型的初始化。

在一个例子中，开发所述第一待测试模块的UVC，包括：根据所述第一设计文档所记载的指令获取第一寄存器的列表并检测所述第一待测试模块的功能模式，并根据所述第一寄存器的列表和所述第一待测试模块的功能模式对所述第一寄存器分配不同的值；其中，所述第一待测试模块的功能模式至少包括：正常工作模式，浅睡眠模式和深睡模式。

在一个例子中，在处理寄存器时，通过Makefile脚本把Excel中寄存器每一张表单自动转化为一个件，一行一个寄存器信息，可以字节或字的形式存在。每个比特以”,”做分割。通过PYTHON脚本转化成对应的reg_model.sv文件，存储器部分嵌套在脚本中，通过测试用例可以前门或后门访问所有寄存器和存储器。根据所述寄存器的列表和待测试模块的功能模式对所述第一寄存器分配不同的值。

在一个例子中，对所述第一待测试模块所需的第一测试序列具体通过以下方式实现：

值得注意的是，每个待开发的模块单独均具有的一个文件，内部包含该模块特有的一些序列。

在seq_lib中，开发模块所需的测试序列类，并做例化，时钟复位参数的配置等。

在测试库文件中，例化各种IP使用的功能类，和总线相关的可以直接调度对应的任务，测试库文件要在上层总库文件里预编译。以下出现的文件均为测试库文件。

·在ip_env_seq_lib.sv中，包括各个IP中用到的TRANS的例化，系统访问memory的自动化类的例化，时钟和复位的例化，各个IP的功能覆盖率统计文件。最后把各个IP的ip_*_seq_lib.sv通过include加载进来。

·在ip_*_seq_lib.sv中，主要包括以下内容，访问寄存器的各种类，例如写寄存器的某个bit，或某个字段，CPU的选择，数据位宽的选择，支持字节，半字，字的操作。轮询某个字段，检查某个字段等。对SLAVE模型的约束类。最后是所有测试用例继承的基类。例如ip_*_test_vseq类，内部声明VIP的类的例化，transaction的例化，上述自行开发的类，在pre_body中，首先产生各个时钟和复位的参数，生成它们。对SLAVE的约束参数配置等。

·在ip_amba_seq_def.svh中定义各种寄存器和内存地址等。

除了在测试库中对各个文件做出了调整，测试序列还需要调整测试用例，测试用例部分的调整如下：值得注意的是，测试用例共分两级目录。

·在ip_testcase_top.sv中，include各个子目录的名字。ip_*_testcase_top.sv,*代表模块名字。各个模块用宏定义进行区分。每次编译时，仅仅编译该模块的内容。

·在*_u/ip_*_testcase_top.sv,include该模块所有的测试用例列表。

·测试用例举例，ip_amba_wr_burst.sv,amba是模块名，wr_burst是测试用例名。测试用例通常调度seq_lib库中的类，可以是现开发或VIP中的。

在一个例子中，开发第一待测试模块所需的第一测试序列后，对所述第一测试序列进行参数例化操作。通过参数控制不同BURST之间延时周期数具体如图4所示。

在一个例子中，对于测试模块的UVC通过如下方式开发：开发modu_uvc(指的是UVM验证组件，里边包含端口激励，监控和数据比对)，主要是transaction(是UVC中的一个文件，用来对所有寄存器和控制信息建立约束关系，每次可生成一组合理的配置值)的开发，此时需要掌握设计文档和寄存器列表，根据功能模式对寄存器配置不同的值，写全部约束。在驱动文件中写出发包步骤，在监控模块中取相应数据到scoreboard中对比。如果用到VIP，可以做适当修改，比如主从个数，地址范围，数据和地址的位宽等。

在步骤103中，获取获取第二待测试模块，并检测所述第二待测试模块的类型，由于已经完整的搭建了一个平台，在另一个类型的模块需要搭建平台时就可以使用共用的信息来进行搭建。所以在步骤104中，获取第一验证平台中的共用信息。

在步骤105中，获取第二设计文档，根据所述第二设计文档和所述共用信息搭建所述第二验证平台。

在一个例子中，所述获取第一验证平台中的共用信息，包括：获取所述第一验证平台中所述开发后的所述第一待测试模块的顶层模块；所述第一待测试模块的顶层模块用于开发所述第二待测试模块中的顶层模块。

在一个例子中，所述根据所述第二设计文档和所述共用信息搭建所述第二验证平台，包括：根据所述第二设计文档，依次开发所述第二待测试模块的UVC、所述第二待测试模块所需的第二测试序列；通过开发后的所述第二待测试模块的UVC、所述第二待测试模块所需的测试序列和所述第二待测试模块的顶层模块搭建所述第二验证平台。

当一个新的模块(第二测试模块)需要搭建环境时，也同样需要进行开发顶层模块，此时可参照其它模块的共用部分，例如CPU模型的连接，VIP的例化，时钟复位的连接等。复制顶层文件，根据IP接口的情况，对总线的参数做出约定，例如地址宽度，数据宽度，时钟生成和复位生成，连接对应总线上的接口，每种接口都有示范连接，连接时钟和复位信号，对应总线VIP的声明，VIP接口时钟信号和复位信号，各个MASTER,SLAVE的声明，可以选择增加一条总线，用来监控接口上的数据收发是否符合AMBA协议，方法是把MASTER发出的数据赋值给监控总线上的一个MASTER口，通过uvm_config_db进行接口的路径指定，在用到模型的地方，需要注释掉对应的路径指定，时钟和复位采用自研的模块，在顶层include一个文件ip_tb_common.sv,里边除了时钟复位的生成，还有一些虚拟的模型例化，主要用在不需要对应模型的DUT的验证，此时路径可以找到，避免编译不过。需要注意的地方是复位信号先给一个指定的0或1，系统在起始时间等待20NS左右，再给复位模型产生的值，时钟是在起始时间直接给定模型的输出信号。在ip_tb_common.sv中还有公共的接口声明和路径指定。

在一个例子中，开发所述第一待测试模块的顶层模块后，还包括：创建用于测试所述第一待测试模块的相关路径或文件列表；所述获取第一验证平台中的共用信息后，还包括：创建用于测试所述第二待测试模块的相关路径或文件列表。

在一个例子中，创建测试用例列表，功能覆盖率和断言的开发等，调试测试用例和环境，回归测试用例。

在一个例子中，所述第一验证平台和所述第二验证平台均包括：AHB Master模型、AHB Slave模型，APB Master模型、APB Slave模型。

模型可与上述设计DUT直接相连，如图5所示。

平台进行测试的AHB或APB的相关模型可以直接使用，不需要复制，整个系统无论多少IP，都共享同一个。内部包括了所有封装好的任务，SLAVE模型要支持极端情况，比如延迟READY的随机周期，RESP(response响应)出错情况。MASTER模型分两层设计，第一层是基本的读事务和写事务，第二层在第一层的基础上做出各种演变，实现各种实际的需求。这些模型的具体细节调整如下：

·在AHB MASTER模型中我们实现了各种TASK，包括校对结果等。在后端仿真时，我们首先运行一个C的测试用例，测量出CPU端口的真实延迟数据，FAST和SLOW值，在模型中使用。

·在SLAVE模型中，需要指定若干参数，包括response延迟使能，随机数延迟值使能，常数延迟值，错误场景使能，WRAP禁止使能等。无论读写都支持背靠背操作，就是无间隙，通过乒乓结果实现。

·在ip_env_seq_def.svh中，宏定义了TRANS的例化，对应各种TASK，包括数据的收集，

参数的传递等。

·在arm_uvc中，实现对上述任务的调用和约束。在ip_arm_bus_def.svh中，包括CPU访问类型的枚举，响应类型的枚举，burst和size的宏定义等。在ip_arm_bus_driver.sv中，根据trans_type的不同，选择不同的CPU访问TASK。在ip_arm_bus_trans.sv中，实现对不同burst类型时，参数的约束。在ip_arm_reg_access_sequence.sv中，实现CPU对寄存器模型的访问，其它文件保持不变。

在CPU中AHB模型部分任务细节如下：

此处是从设备参数控制类对其中重要参数的控制。响应延迟是否使能，随机的延迟周期使能是否设置有效，常数的延迟周期数，错误使能是否有效，回绕操作是否支持。下面所有AHB任务发起前，都可以调用这个类，约束从模型。

·实现任意一个burst类型的访问，限定是一次写操作，或者类型“ALL“依次发全部类型SINGLE,INCR,WRAP4,INCR4,WRAP8,INCR8,WRAP16,INCR16各一次，之间的间隔周期可以指定。输入参数包括起始地址，数据宽度，BURST类型，BURST之间的延迟，BUSY使能，写数据和INCR长度由事务约束产生。上层调用时分两种任务，区别点是部分控制参数和写数据由TRANSACTION事务随机生成。输出参数包括写到SLAVE设备的数据数组和从SLAVE回来代表写操作是否错误标识。

·实现任意burst类型的若干次访问，SINGLE,INCR,WRAP4,INCR4,WRAP8,INCR8,WRAP16,INCR16，该类型的写操作次数是随机的，从一次到若干次，之间的间隔周期可以指定。上层调用时分两种任务，区别点是部分控制参数和写数据数组由TRANSACTION事务随机生成。输入参数包括起始地址，BURST次数，BUSY使能，其余所有参数由事务约束产生。输出参数是从SLAVE回来代表写操作是否错误标识，若干次的写操作，任何一次错误，就回复错标识。

·实现任意一个burst类型的若干次写访问和同样类型的读访问，SINGLE,INCR,WRAP4,INCR4,WRAP8,INCR8,WRAP16,INCR16，步骤是,先完成写操作，然后是一次读操作，重复读写操作若干次，之间的间隔周期可以指定。等全部读写次数都完成，对所有的BURST数据做比对。上层调用时分两种任务，区别点是部分控制参数和写数据数组由TRANSACTION事务随机生成。输入参数包括起始地址，数据宽度，BURST类型，BURST次数，BURST之间的延迟，BUSY使能，写数据数组和INCR长度由事务约束产生。输出参数是从SLAVE回来代表写操作是否错误标识，若干次的写操作和读操作，任何一次错误，就回复错标识。

·传输若干次BURST,每次的地址，SIZE,BURST,INCR_LENGTH,BURST_DELAY,BUSY_EN都是随机的,每一次BURST传输，写完成后，按照同样的BURST类型读出并比对结果。

·实现任意一个burst类型的访问，限定是一次读操作，或者类型“ALL“依次发全部类型SINGLE,INCR,WRAP4,INCR4,WRAP8,INCR8,WRAP16,INCR16各一次，之间的间隔周期可以指定。输入参数包括起始地址，数据宽度，BURST类型，BURST之间的延迟，BUSY使能，INCR长度。上层调用时分两种任务，和写操作配合使用，区别点是控制参数是人工指定或由TRANSACTION事务随机生成。输出参数包括从SLAVE设备读回的数据数组和从SLAVE回来代表读操作是否错误标识。

·实现任意一个burst类型的访问，SINGLE,INCR,WRAP4,INCR4,WRAP8,INCR8,WRAP16,INCR16，限定是同样的BURST类型的若干次读操作，每个BURST之间的间隔周期可以指定。输入参数包括起始地址，数据宽度，BURST类型，BURST之间的延迟，BUSY使能，INCR长度。上层调用时分两种任务，区别点是控制参数是人工指定或由TRANSACTION事务随机生成。写操作的参数通过TRANSACTION事务输出传递到读操作；

输出参数是从SLAVE读回的BURST数据数组，和从SLAVE回来的状态，代表读操作是否错误和数据比对结果是否错误，任何一个有错，就返回错误标识。

·实现任意burst类型的访问，随机BURST类型的若干次读操作，之间的间隔周期可以指定。读操作全部完成后，对所有BURST的数据做比对。输入参数包括起始地址，数据宽度，BURST类型，BURST之间的延迟，BUSY使能，INCR长度，参考比对数据数组。上层调用时分两种任务，区别点是控制参数是人工指定或由TRANSACTION事务随机生成。写操作的参数通过TRANSACTION事务输出传递到读操作；输出参数是从SLAVE回来的状态，代表读操作是否错误和数据比对结果是否错误，任何一个有错，就返回错误标识。

对于CPU中APB模型部分任务细节具体如下：由于从设备参数控制类对其中重要参数的控制。响应延迟是否使能，随机的延迟周期使能是否设置有效，常数的延迟周期数，错误使能是否有效。下面所有APB任务发起前，都可以调用这个类，约束从模型。

·单个APB写操作，可以写任何字节/半字/字，常规访问寄存器用。

·单个APB读操作，读出整字，常规访问寄存器用。

·单个APB写操作，完成后，等待随机周期延迟。SIZE是字节时，根据低两位地址的不同，pstrb_arr[i]取值4’b0001/4’b0010/4’b0100/4’b1000；SIZE是半字时，根据低两位地址的不同，pstrb_arr[i]取值4’b0011/4’b1100；SIZE是字时，pstrb_arr[i]取值4’b1111；

·单个APB写操作，等待延迟若干周期，单个读操作，等待延迟，比对数据。

·单个APB读操作，完成后等待随机时钟周期延时，并输出读数据。

·单个APB读操作，并比对数据结果。

·连续写操作，参数随机。

·连续写N个数据，随机写多笔数据。

·连续写读操作，写一次，加延时，读一次，并比较结果。

·连续读操作，返回四字节对齐的字，为比对做准备。

·连续写N个数据，连续读N个数据，逐个比较数据。

上述写操作的两层结构，底层是基本写操作，上层有多种演化场景，比如随即写，写完后读并校对结果等。应对各种实际需要，采用的特定结构，优势是公共部分独一份，保证了稳定性，附加部分处理各种特定场景，是平台独有的。具体如图6所示。

上述为读操作的两层结构，底层是基本读操作，上层是多种读操作的演变，比如读并校对，随机读事务等，应对各种实际需要，采用的特定结构，优势是公共部分独一份，保证了稳定性，附加部分处理各种特定场景，是平台独有的具体如图7所示。

为便于理解上述平台搭建方法，此处给出平台的测试方法步骤，具体如下：

新模块需要在uvm_tests下创建模块对应的目录modu_u，把测试用例列表文件名ip_modu_testcase_top.sv加入ip_testcase_top.sv中。在modu_u目录下创建测试用例和测试用例列表文件名。测试用例的创建是从别的模块复制一个用例，删除调用序列部分，替换关键字后，就是一个空的测试用例。分成三部分，第一部分是序列的配置部分，主要是一些初始化配置，用后门访问配置寄存器或大块存储空间。第二部分是测试序列，主要是调用库中已开发的序列或第三方VIP的序列。CPU不同类型的读写调用自tb/chip_env/seq_lib/ip_env_seq_def.sv，内部对各种事务的约束做了宏定义，在测试用例或序列库中直接使用。在测试用例中，这部分是主体，除了若干序列外，也可加入适当的控制信息，共同组成一个测试场景，其中所有的存储器访问都可以调用相关序列，并采用自动回读数据比对或直接后门访问的方式抓取并比对数据包。第三部分是test的宏，比如想修改在出错时，测试用例只报警告，仍然继续运行结束等。

测试时采用灰盒测试，首先是根据模块文档的说明，提取属性列表，可以使用VManager工具，列出所用测试点，分几个大块，时钟测试，复位测试，模式测试，中断测试，交叉测试等。每个属性都有对应的测试用例或序列。在EXCEL表中，列出计划开发的序列和测试用例，对每个序列或用例写出具体的操作步骤。同步开发功能覆盖率和断言，主要用来检查状态机的跳转序列和主要功能点的覆盖情况。当完成全部测试用例的回归后，分析代码覆盖率和功能覆盖率情况，增加相关测试场景在理想情况下使覆盖率达到百分之百，确有未覆盖的要说明详细原因。功能覆盖率要完全覆盖。

芯片所有设计模块验证完成后，需要做系统级测试，需要把模块级环境移植到系统平台上，驱动部分可能会关闭，只留监控部分，取决于模块在芯片中的位置，最前端是保留的，中部关闭，尾部若有驱动保留。数据比对部分保持不变。测试用例可能要做适当修改，出错时，找到对应模块的端口数据分析错误原因。如果是模块自身设计问题，反馈到模块级环境增加测试用例覆盖该情况。

对低功耗切换场景下，存储单元的验证，先做写操作并校对，等系统睡眠，过一段时间，系统唤醒，再做读操作并比对数据。如图8所示。

系统级前仿完成后，做门级仿真，然后是带延时信息的网表FAST和SLOW仿真，有时候由于延时参数的原因，后仿和前仿的参数配置可能不一样，涉及到修改配置的问题。

全部完成后，功能验证就完成了，此时要不断地回归，如果发现错误，再修复设计或者验证环境。

在本实施方式中，获取第一待测试模块，并检测所述第一待测试模块的类型；根据所述第一待测试模块的类型获取对应的第一设计文档，根据所述第一设计文档搭建第一验证平台；所述第一验证平台用于对所述第一待测试模块进行测试；获取第二待测试模块，并检测所述第二待测试模块的类型；若所述第一待测试模块的类型与所述第二待测试的类型不同，则获取第一验证平台中的共用信息；获取第二设计文档，根据所述第二设计文档和所述共用信息搭建所述第二验证平台，通过根据不同的模块类型搭建平台，再根据对应的设计文档构建用于测试的验证平台，若需要验证的测试模块类型不同，在整个项目验证的各个阶段，都不需要大的改动，只需微调即可。IP级的测试用例在系统级平台上可以复用，保证了不论是什么技术水平的工程师，模块的使用什么接口，验证都达到同样的水平，同时保证了验证中整个通路上的各模块融合无误，不存在模块之间的冲突。上面方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。

值得一提的是，本实施方式中所涉及到的各模块均为逻辑模块，在实际应用中，一个逻辑单元可以是一个物理单元，也可以是一个物理单元的一部分，还可以以多个物理单元的组合实现。此外，为了突出本发明的创新部分，本实施方式中并没有将与解决本发明所提出的技术问题关系不太密切的单元引入，但这并不表明本实施方式中不存在其它的单元。

本发明的另一实施方式涉及一种电子设备如图9所示，包括至少一个处理器901；以及，与至少一个处理器901通信连接的存储器902；其中，存储器902存储有可被至少一个处理器901执行的指令，指令被至少一个处理器901执行，以使至少一个处理器901能够执行如上述的验证平台搭建方法。

其中，存储器902和处理器901采用总线方式连接，总线可以包括任意数量的互联的总线和桥，总线将一个或多个处理器901和存储器902的各种电路连接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路连接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器901处理的数据通过天线在无线介质上进行传输，进一步，天线还接收数据并将数据传送给处理器901。

处理器负责管理总线和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器可以被用于存储处理器在执行操作时所使用的数据。

本发明另一实施方式涉及一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述方法实施例。

即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域的普通技术人员可以理解，上述各实施方式是实现本发明的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。

Claims (10)

1.一种验证平台搭建方法，其特征在于，包括：

获取第一待测试模块，并检测所述第一待测试模块的类型；

根据所述第一待测试模块的类型获取对应的第一设计文档，根据所述第一设计文档搭建第一验证平台；所述第一验证平台用于对所述第一待测试模块进行测试；

获取第二待测试模块，并检测所述第二待测试模块的类型；

若所述第一待测试模块的类型与所述第二待测试的类型不同，则获取第一验证平台中的共用信息；

获取第二设计文档，根据所述第二设计文档和所述共用信息搭建所述第二验证平台。

2.根据权利要求1所述的验证平台搭建方法，其特征在于，所述根据所述第一设计文档搭建第一验证平台，包括：

根据所述第一设计文档，依次开发所述第一待测试模块的UVC、所述第一待测试模块所需的第一测试序列和所述第一待测试模块的顶层模块，通过开发后的所述第一待测试模块的UVC、所述第一待测试模块所需的测试序列和所述第一待测试模块的顶层模块搭建所述第一验证平台。

3.根据权利要求2中所述的验证平台搭建方法，其特征在于，所述获取第一验证平台中的共用信息，包括：

获取所述第一验证平台中所述开发后的所述第一待测试模块的顶层模块；

所述第一待测试模块的顶层模块用于开发所述第二待测试模块中的顶层模块。

4.根据权利要求3中所述的验证平台搭建方法，其特征在于，所述方法还包括：

所述开发所述第一待测试模块的顶层模块后，还包括：创建用于测试所述第一待测试模块的相关路径或文件列表；

所述获取第一验证平台中的共用信息后，还包括：创建用于测试所述第二待测试模块的相关路径或文件列表。

5.根据权利要求3中所述的验证平台搭建方法，其特征在于，所述根据所述第二设计文档和所述共用信息搭建所述第二验证平台，包括：

根据所述第二设计文档，依次开发所述第二待测试模块的UVC、所述第二待测试模块所需的第二测试序列；

通过开发后的所述第二待测试模块的UVC、所述第二待测试模块所需的测试序列和所述第二待测试模块的顶层模块搭建所述第二验证平台。

6.根据权利要求2所述的验证平台搭建方法，其特征在于，所述开发所述第一待测试模块的UVC，包括：

根据所述第一设计文档所记载的指令获取第一寄存器的列表并检测所述第一待测试模块的功能模式，并根据所述第一寄存器的列表和所述第一待测试模块的功能模式对所述第一寄存器分配不同的值；

其中，所述第一待测试模块的功能模式至少包括：正常工作模式，浅睡眠模式和深睡模式。

7.根据权利要求2所述的验证平台搭建方法，其特征在于，所述方法还包括：

所述开发第一待测试模块所需的第一测试序列后，对所述第一测试序列进行参数例化操作。

8.根据权利要求1所述的验证平台搭建方法，其特征在于，所述第一验证平台和所述第二验证平台均包括：

AHB Master模型、AHB Slave模型，APB Master模型、APB Slave模型。

9.一种电子设备，其特征在于，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1至8中任一所述的验证平台搭建方法。

10.一种计算机可读存储介质，存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至8中任一项所述的验证平台搭建方法。