一种基于UVM的应答器芯片多模块同步验证平台和验证方法与流程

一种基于uvm的应答器芯片多模块同步验证平台和验证方法
技术领域
1.本发明属于芯片验证领域，特别涉及一种基于uvm的应答器芯片多模块同步验证平台和验证方法。


背景技术：

2.现有应答器芯片没有涉及到使用uvm验证平台来验证应答器模块。过去针对应答器芯片的仿真验证平台基于简单的verilog代码，给输入输出端口施加简单激励，并没有存在系统性、模块化的方式来全方位的验证应答器芯片，由此导致了应答器芯片中很多bug并没有及时被发现。
3.随着集成电路行业的不断发展，芯片的设计部分的复杂度越来越大，芯片规模成比例增加，给验证带来了困难。芯片需要多次流片失败之后才能成功流片，提高验证的完备性是成功流片的必要条件，因此提高验证效率是目前极为迫切的任务。并且据统计，在整个芯片项目周期中，验证环节所用的周期逐渐占到总项目周期的80％，验证技术已经跟不上设计和制造能力的发展，已经成为制约芯片设计行业发展的瓶颈。
4.现阶段验证领域应用的功能验证方法主要有动态验证和原型系统验证等。动态验证主要是指利用仿真器对待测设计进行仿真来判断待测设计的功能是否正确的一种手段。动态验证方法中传统的验证技术是基于verilog语言编写的定向测试，针对待测设计的不同特性逐一构造测试激励序列并施加于待测设计中，采用观测波形和踪迹文件的方式判断目标设计是否实现了预期的功能。传统验证技术verilog语言受限于静态例化，无法随仿真情况做动态变换，使用其搭建的验证平台在结构上缺乏层次化，传统的验证技术关注的更多集中在信号层次，而随着集成电路复杂度增大、设计的抽象层次不断提高，传统验证方法已经不再适用。
5.原型系统验证是利用fpga可编程、资源丰富等优点，在数字系统设计流片之前把rtl设计模型综合映射到fpga单元上构成原型系统，通过逻辑分析仪采样观测原型系统内的信号和状态，从而分析设计的功能是否正确。此验证方法可以降低大型系统设计的开发成本，快速仿真出设计的逻辑能力，但是fpga原型系统验证的信号可见度差，并且在正常情况下极端边界的验证很难进行，极端情况的测试只能在出现特殊情况下才能进行，一般适用于稳定的后期系统设计集成验证，不适用于芯片开发前期的功能验证。
6.应答器芯片中通常包含多个功能模块，应答器整体联动的工作过程通常是多个模块联动的结果，而常见的验证平台是对各个功能模块进行一一验证，不仅效率低，而且不能仿真应答器实际应用场景。


技术实现要素：

7.针对上述问题，本发明提供了一种基于uvm验证方法的应答器芯片多模块同步验证平台和验证方法，能够仿真应答器实际应用场景，并提高验证效率。
8.本发明的一种基于uvm的应答器芯片多模块同步验证平台，包括：
9.激励序列生成模块，用于产生transaction数据包，其中，根据应答器的帧信息，配置所述transaction数据包；
10.写代理器，用于从所述激励序列生成模块获取写码transaction数据包并驱动待验证应答器的写码模块，对所述待验证应答器的写码模块和读码模块进行仿真验证；
11.有源代理器，用于从所述激励序列生成模块获取有源transaction数据包并驱动所述待验证应答器的有源模块，对所述有源模块进行仿真验证；
12.检测器组件，用于采集所述待验证应答器输出的实际数据，并发送给计分板；
13.参考模型组件，用于生成参考数据并发送给所述计分板；
14.计分板，用于将所述实际数据与所述参考数据进行对比后获取所述待验证应答器的验证结果。
15.进一步地，所述写代理器包括封装在一起的写激励序列管理模块与写驱动器；
16.其中，所述写激励序列管理模块用于从所述激励序列生成模块获取所述写码transaction数据包并传递给所述写驱动器；
17.所述写驱动器用于将所述写码transaction数据包分解为信号级数据，并通过接口模块驱动所述写码模块。
18.进一步地，所述有源代理器包括封装在一起的有源激励序列管理模块与所述有源驱动器；
19.其中，所述有源激励序列管理模块用于从所述激励序列生成模块获取所述有源transaction数据包并传递给所述有源驱动器；
20.所述有源驱动器用于将所述有源transaction数据包分解为信号级数据，并通过接口模块驱动所述有源模块。
21.进一步地，还包括：
22.虚拟激励序列管理模块，所述虚拟激励序列管理模块桥接所述写激励序列管理模块与所述有源激励序列管理模块；
23.所述虚拟激励序列管理模块具有指向写激励序列管理模块与有源激励序列管理模块的指针，并用于控制和调度所述写激励序列管理模块与所述有源激励序列管理模块。
24.进一步地，所述检测器组件包括：
25.eeprom输入检测器，用于检测所述读码模块与应答器芯片的内存模块eeprom之间端口的信号变化，并将输入到所述读码模块端口的信号级数据打包并恢复成transaction数据包级别后传递给所述计分板；
26.读模块输出检测器，用于监视所述读码模块和所述有源模块的输出端口的信号变化，并将采集到的所述读码模块和所述有源模块的输出端口的信号级数据转变为transaction数据包级别并传递给所述计分板。
27.进一步地，所述参考模型组件包括：
28.读模型，用于完成所述写码模块和所述读码模块相同的功能，并输出对应的参考数据传递给所述计分板；
29.有源模型，用于完成所述有源模块相同的功能，并输出对应于有源模块的参考数据传递给所述计分板。
30.本发明还提供一种基于uvm的应答器芯片多模块同步验证方法，包括下面步骤：
31.写代理器获取写码transaction数据包并驱动应答器写码模块，有源代理器获取有源transaction数据包并驱动应答器有源模块；
32.写码模块对所述写码transaction数据包进行解析获取控制命令，并分析判断所述控制命令是否为：读有源信号命令；
33.若所述控制命令非读有源信号命令，则所述写码模块将所述控制命令发送给读码模块，所述读码模块根据接收到的所述控制命令进行应答器功能验证；
34.若所述控制命令为读有源信号命令，则所述读码模块从所述有源模块中读取有源数据后，进行有源信号的读写验证。
35.进一步地，所述控制命令包括：写码命令、读id命令、无源命令和读有源信号命令。
36.进一步地，所述的读码模块根据接收到的所述控制命令进行应答器功能验证包括下面步骤：
37.当所述写码模块解析所述写码transaction数据包获取的控制命令为：写码命令、读id命令或无源命令时，驱动所述读码模块；
38.当控制命令为写码命令时，所述读码模块在接收到所述写码命令后建立通道，将对应的写码时序输出到应答器芯片的内存模块eeprom；
39.当控制命令为读id命令或无源命令时，所述读码模块在接收到所述读id命令或所述无源命令后建立通道，将所述内存模块eeprom中的响应命令读取出来；
40.eeprom输入检测器采集内存模块eeprom的地址数据，传输到读模型中，读模型模拟ram的功能产生预期eeprom的数据作为第一参考数据；
41.读模块输出检测器采集内存模块eeprom端口的第一实际数据；
42.在计分板中对比所述第一参考数据与所述第一实际数据，并根据对比结果分析获取验证结果。
43.进一步地，对比所述第一参考数据与所述第一实际数据是否一致：
44.如果所述第一参考数据与所述第一实际数据一致，则验证完成；
45.如果所述第一参考数据与所述第一实际数据不一致，则暂停验证，进行查找问题操作和修正错误操作后，重新进行验证。
46.进一步地，所述的有源信号的读写验证包括步骤：
47.所述有源模块建立有源通道，所述读码模块从所述有源模块中读取有源数据；
48.eeprom输入检测器采集所述读码模块从所述有源模块中读取到的有源数据作为第二实际数据；
49.有源模型从有源代理器中获取有源transaction数据包，并对所述有源transaction数据包进行码元转换后传递到计分板中作为第二参考数据；
50.在计分板中对比所述第二参考数据与所述第二实际数据，并根据对比结果分析获取验证结果。
51.进一步地，
52.对比所述第二参考数据与所述第二实际数据是否一致：
53.如果所述第二参考数据与所述第二实际数据一致，则验证完成；
54.如果所述第二参考数据与所述第二实际数据不一致，则暂停验证，进行查找问题操作和修正错误操作后，重新进行验证。
55.本发明的基于uvm验证方法的应答器芯片验证平台和验证方法，待测设计为应答器芯片的写码模块、读码模块和有源模块，考虑到了应答器芯片工作过程中多个模块之间的联动。将三个模块同时例化为待测设计dut进行仿真验证更加符合应答器芯片读码模块、写码模块与有源模块之间的相互配合运行关系，可以做到对实际环境的更贴近的仿真。把三个模块当成一个整体进行验证，相比于单独模块进行验证，把部分外部接口变成内部接口信号，减少了需要施加接口激励的数量，同时模块间信号配合更加密切，需要一个模块对另一个模块的配合输出，调试的时候需要联合观察信号，体现了应答器三个模块的协调一致工作；能够同时验证多个应答器芯片中的功能模块，能够提高应答器芯片的验证效率。
56.本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在说明书、权利要求书以及附图中所指出的结构来实现和获得。
附图说明
57.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
58.图1示出了根据本发明实施例基于uvm的应答器芯片多模块同步验证平台架构示意图；
59.图2示出了根据本发明实施例基于uvm的应答器芯片多模块同步验证方法的数据流程图。
具体实施方式
60.为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地说明，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
61.通用验证方法学(universal verification methodology，uvm)是一个以systemverilog类库为主体的验证平台开发框架，验证工程师可以利用其可重用组件构建具有标准化层次结构和接口的功能验证环境。近些年来，由于uvm验证方法不仅克服了传统验证方法的不足，并且在搭建验证环境中具有明显优势，uvm验证方法学采用system verilog的验证语言，system verilog是一个verilog的扩展集，并且可以完全兼容verilog。它具有面向对象语言的特征：封装、继承和多态，同时还为验证提供了一些独有的特性，如约束(constraint)、功能覆盖率(functional coverage)等。
62.uvm是一个以system verilog类库为主体的验证平台开发框架，验证工程师利用其可重用组件可以构建具有标准化层次结构和接口的功能验证环境。uvm验证方法学有效结合了测试激励随机生成、自测试平台和随机化约束等方法，它采用最佳框架以实现覆盖率驱动的验证，使验证工程师通过采用高级验证技术来降低风险，满足缩短产品上市时间的迫切需求。
63.验证平台的作用是找出设计中可能出现的错误，本发明将基于uvm高级验证方法的搭建应答器芯片的验证环境。本发明的一种基于uvm的应答器芯片的验证平台结构包括：
64.待测设计(device undertest，dut)和验证组件，验证组件和待测设计dut通过sv(system verilog)接口(interface)进行互联，从而对待测设计dut的接口与待测设计dut的实际系统功能进行测试，确保待测设计dut组装后能够按既定的逻辑运行，实现相应的功能。
65.使用uvm验证方法学和systemverilog语言搭建验证环境，验证组件基于uvm方法学，验证组件的各个部分之间以tlm接口(transaction level model，事务级建模)进行数据通信。
66.基于uvm的应答器芯片验证平台的组成结构如图1所示，如图1所示，本发明的一个具体实施例中，待测设计dut为应答器芯片，由于应答器芯片工作过程中不会同时使用三个模块，因此本发明的实施例中待测设计dut包括应答器芯片的写码模块dut1(u_write)、读码模块dut2(u_read)与有源模块dut3(u_volatile)，并对这三个模块进行验证。
67.本发明是一种基于uvm的应答器芯片多模块同步验证平台，并基于该验证平台，提供了一种应答器芯片的多模块同步验证方法，用于对应答器芯片进行验证。
68.参见图1，本发明的一个具体实施例中，验证组件包括：
69.激励序列生成模块sequence，sequence用于产生transaction数据包，即产生符合约束的随机测试激励，即根据测试的模块对应生成transaction数据包。其中，所述transaction数据包是根据应答器的帧信息来配置的。根据应答器的帧信息，配置transaction数据包相当于配置应答器帧的各项参数，数据交换是以帧为单位进行交换。本发明中应答器帧信息主要包括输入配置命令、操作命令、控制命令、地址、写数据、读数据等。配置输入命令分为读无源或有源命令、写码命令、读有源默认命令、读id命令与无效命令。dbpl码(differential biphase level)这里设为为单比特，每条有1024位的数据包。
70.激励序列管理sequencer，用于将所述随机测试激励发送给驱动器driver；
71.本实施例中激励序列管理sequencer包括write_sequencer(写激励序列管理模块)和volatile_sequencer(有源激励序列管理模块)，其中，write_sequencer与volatile_sequencer通过virtual_sequencer(虚拟激励序列管理模块)连接，virtual_sequencer具有指向write_sequencer与volatile_sequencer的指针，来控制write_sequencer与volatile_sequencer，其作用类似于中心路由器，起到统一调度的作用。
72.驱动器driver，用于将所述随机测试激励驱动待测设计dut端口；
73.本实施例中驱动器driver包括write_driver(写驱动器)与volatile_driver(有源驱动器)，其中，write_driver与volatile_driver作为测试平台中的驱动器，主要负责分别将write_sequencer与volatile_sequencer传递的transaction数据包进行分解后变成信号级数据，然后通过interface模块驱动待测设计dut。
74.具体地，write_driver与volatile_driver在验证平台中起到了承上启下的作用，数据在sequence内被打包，在virtual_sequencer的控制下，分别被发送到write_sequencer与volatile_sequencer内，write_sequencer与volatile_sequencer用于检测仲裁队列中是否有发送transaction数据包的请求，并用于检测write_driver与volatile_driver是否申请transaction数据包的请求，并负责将sequence生成的transaction数据包
分别传递给write_driver与volatile_driver。transaction数据包分别经过write_driver与volatile_driver，再通过interface模块后变为信号级被施加到待测设计dut上。
75.由于uvm提供了丰富的类库，所以在设计write_driver与volatile_driver时，首先需要从uvm提供的uvm_driver类中派生出write_driver类与volatile_driver类。在代码核心部分的开始，需要对write_driver类与volatile_driver类进行factory(类厂)注册，采用factory机制能够自动的为一个类创建实验证平台例并调用其中包含的函数及任务。
76.参考模型组件，用于生成参考数据并发送给计分板(scoreboard)；
77.参考模型组件包括read_model(读模型)和volatile_model(有源模型)，用于完成和对应待测的模块dut相同的功能，得到预期结果，参考模型组件输出的参考数据发送到计分板，并被计分板接收，用于和待测的模块dut输出的实际数据进行比较。
78.其中，通过应答器芯片的内存模块eeprom(electrically erasable programmable read onlymemory，带电可擦可编程只读存储器)存储实际数据。
79.检测器组件，用于采集待验证应答器输出的实际数据(即采集待测设计dut端口输出的数据)，并传递给计分板；
80.检测器组件包括：
81.eeprom_imonitor(eeprom输入检测器)，用于检测读码模块与内存模块eeprom之间端口的信号变化，并将输入到读码模块端口的信号级数据打包并恢复成transaction数据包级别后传递给计分板；
82.read_omonitor(读模块输出检测器)，用于监视读码模块和有源模块的输出端口的信号变化，并将采集到的读码模块和有源模块的输出端口的信号级数据转变为transaction数据包级别并传递给计分板。
83.scoreboard(计分板)，用于将采集的实际数据与参考模型生成的参考数据进行对比后获取待验证应答器(正在验证的模块)的验证结果。
84.transaction数据包的传递过程为：当driver向sequencer索要transaction数据包时，sequencer会转而向sequence要数据，当sequence发现有transaction数据包时，则将transaction数据包传输给sequencer。
85.参见图1和图2，write_driver用于驱动dut1(u_write)接口，volatile_driver用于驱动dut3(u_volatile)接口及dut2(u_read)的部分接口。
86.如图1所示，检测器monitor包括eeprom_imonitor和read_omonitor。
87.eeprom_imonitor用来检测dut2与eeprom之间端口信号的变化，eeprom_imonitor负责将输入到dut2信号端口的信号级数据打包并恢复成数据包级，eeprom_imonitor将dut2端口的cs(eeprom的输出控制线)、cp(eeprom的时钟输入线)与di(eeprom的操作命令与数据线)信号采集转换成eeprom的地址，然后把eeprom的地址信息发送给read_model。
88.read_omonitor用于监视dut(包括dut2和dut3)的输出端口信号的变化，获取dut输出端口数据，并将dut的端口中的数据转变为transaction数据包级别，并传递给计分板(scoreboard)处理。
89.具体地，read_omonitor采集dut2的端口数据包括两部分，一部分是eeprom端口的数据(即dut2与eeprom之间端口信号变化)，另一部分属于有源模块dut3(u_volatile)的数据；然后把采集到的数据交给计分板(scoreboard)。read_omonitor不做分类数据的判断，
由计分板(scoreboard)来执行分类数据的判断。
90.read_model完成了接受从eeprom_imonitor中传入的eeprom地址，并把eeprom的数据传输出去的过程；volatile_model完成数据流有源模块的读写过程，两个model共同完成了和dut相同的功能。read_model与volatile_model从iagent模块(写代理器和有源代理器)中得到了transaction数据包，并把transaction数据包传递给计分板(scoreboard)。在uvm中，通常使用tlm接口实现各个验证组件之间的transaction级别间的通信。
91.由于read_omonitor需要通过interface与dut建立连接，所以在代码内需要声明vif(virtual interface，虚拟接口)，本实施例中是声明了一个uvm_analysis_port的类，声明该种类的目的是为了方便检测器组件(read_omonitor或者eeprom_imonitor)与其他模块之间的交互。其中“uvm_analysis_port”为uvm验证方法中的基础类，用于传递transaction数据包。
92.参见图1，本发明的一个较佳实施例中，采用代理器agent将sequencer和driver封装在一起，将write_sequencer与write_driver实例化后封装在write_iagent(写代理器)内，将volatile_sequencer与volatile_driver实例化后封装在volatile_iagent(有源代理器)内。之后验证平台只需要通过agent模块便可建立与待测设计dut之间的连接，使得uvm验证平台的树形结构更加清晰。其中，driver和sequencer均为uvm验证方法中的基础组件类型，本技术根据应答器芯片的具体情况基于uvm_sequencer类拓展了volatile_sequencer类。
93.eeprom_iagent(eeprom输入代理器)与read_oagent(读模块输出代理器)分别用来封装eeprom_imonitor与read_omonitor，这里is_active变量需要设置成uvm_passive模式，此时在输出端口不需要驱动任何信号，只需要检测信号，端口上只需要检测器组件monitor(read_omonitor或者eeprom_imonitor)，而不用将driver进行实例化。
94.记分板scoreboard模块即记分板模块，用于根据dut的输出来判断dut的行为是否与预期相符合，预期即为参考模型生成的参考数据。实现将接收端dut的read_oagent的read_omonitor实际得到的数据和发送端read_model与volatile_model的预期得到的输出数据进行比较。计分板(scoreboard)根据判断条件来实现两路数据的对比。
95.其中，read_omonitor收集到的eeprom实际数据(即dut端口输出数据，内存模块eeprom与待测设计dut相连，端口也是连在一起的)与read_model预期的eeprom数据的进行对比；read_omonitor收集到的有源模块的实际数据与volatile_model预期的有源transaction数据包进行对比。
96.具体的比对过程为：通过exp_port(预期端口)来获取read_model与volatile_model的数据，通过act_port(实际端口)来获取read_omonitor的数据。具体地，在main_phase中通过fork建立起两个进程，一个进程处理exp_port的数据，当收到数据后，把数据放入expect_queue中；另外一个进程处理act_port的数据，即应答器芯片dut的输出数据，当收集到这些数据后，从expect_queue(预期队列)中弹出之前从exp_port收到的数据，并且调用transaction的compare函数进行数据比较，如果两个数据一致，则验证/仿真完成，如果两个数据不一致，则验证过程暂停，需要在进一步查找问题和修正错误后重新进行应答器芯片验证。
97.如图2所示，本发明的验证平台在具体进行应答器芯片验证时，与待测设计dut之
间的操作数据流包括两部分：
98.1、当操作命令分析为写码、读id或者无源信号时，write_driver驱动dut1(u_write)接口，通过dut2(u_read)建立通道，然后访问内存模块eeprom中存储的数据。
99.2、当操作命令分析为读有源信号时，volatile_driver用于驱动dut3(u_volatile)模块，然后通过dut2(u_read)完成有源信号读写过程。
100.常见的tdy型应答器设备分为有源应答器和无源应答两种设备，设备的系统架构分为有源电路部分和无源电路部分。其中有源应答器由无源电路部分和有源电路部分组成，无源应答器仅由无源电路部分组成。
101.其中所述的应答器芯片由读码模块、写码模块和有源模块a、有源模块b四个功能模块以及应答器芯片外围的模块(包括时钟管理、复位同步和信号同步模块)与内存模块eeprom组成。
102.应答器即dut的数据流传输方式为：应答器启动写码模块，分析dbpl码编码规则，解析出码元数据，进行数据命令的操作，当接收到写码控制命令后，读码模块建立通道，将对应的写码时序输出到eeprom；当接收到输出有源报文命令，启动有源模块，读码模块建立输出有源报文通道。
103.参见图1和图2，本发明的一个具体实施例中，基于uvm的应答器芯片验证平台与待测设计dut之间的联动过程包括如下两个过程：
104.1、写代理器(write_agent模块)获取写码transaction数据包并驱动应答器写码模块，即图中dut1(u_write)，dut1(u_write)按照传码速率与dbpl码编码规则，解析出码元数据，进行数据命令的分析，当解析为写码(包括写id及写报文)或者读id、无源命令后，控制对应的控制线，置为对应的电平；
105.紧接着读码模块dut2(u_read)被驱动，如果是写码控制命令，dut2(u_read)接收到命令后，建立通道，将对应的写码时序输出到内存模块eeprom；如果是读id或者无源控制命令，dut2(u_read)接收到命令后，建立通道，将内存模块eeprom中的响应命令读取出来。
106.然后eeprom_imonitor采集内存模块eeprom的地址数据，传输到read_model中，read_model模拟内存(ram，随机存取存储器)的功能产生预期eeprom的数据作为第一参考数据(即生成的参考数据与内存模块eeprom中的数据类型/格式相同，便于后续的比较)；read_omonitor从eeprom端口采集的数据作为第一实际数据，在计分板(scoreboard)中对比第一参考数据与第一实际数据是否一致，如果一致，则仿真/验证结束，如果对比不一致，则查找问题，修改错误。
107.2、有源代理器(volatile_agent)获取有源transaction数据包，并驱动应答器有源模块，即图1中的有源模块dut3(u_volatile)，在写码模块dut1(u_write)解析到是有源码元命令的模块时，有源模块dut3(u_volatile)建立有源通道，应答器读码模块即图1中的dut2(u_read)从dut3(u_volatile)模块中读取有源数据；volatile_model从有源代理器中获取有源transaction数据包，并对有源transaction数据包进行码元转换；将1024bit的transaction码元转换成32bit
×
32bit的码元后，传递到计分板中作为第二参考数据；read_imonitor采集dut2(u_read)中读取dut3(u_volatile)中的有源数据作为第二实际数据，然后计分板(scoreboard)对比read_omonitor与volatile_model的第二实际数据与第二参考数据是否一致，如果一致，则仿真结束，如果对比不一致，则重新查找问题，修改错
误。具体流程图如图2所示。
108.本发明具体对写码模块、读码模块和有源模块进行了同步验证，本发明的验证平台也可以对每个模块进行单独的验证：如果是对每个模块单独验证，只需要关注单个模块的内部以及外部信号情况，是否实现单一模块的功能，而不考虑其他模块的联动情况。
109.例如单独验证写码模块，需要对来自于读码与有源模块的输入命令进行解析，检验写码模块对这些信号的处理，然后观察输出信号是否有效，并没有考虑到读码模块或者有源模块工作时，产生的动态信号对于写码模块的影响，单独验证会使验证不充分。
110.本发明以上流程是同时对写码模块dut1(u_write)、读码模块dut2(u_read)与有源模块dut3(u_volatile)这三个模块进行验证的流程，本发明采用三个模块联合验证更符合应答器实际应用场景，并且三个模块联合验证可以使得应答器整体工作过程调动起来，最终达到三个模块协同工作，这种情况下，验证更符合应答器整体联动的工作过程。
111.尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。