CN117892661A - 一种基于risc-v处理器验证的模拟器比对系统 - Google Patents

Abstract

本发明公开了一种本发明公开了一种基于RISC‑V处理器验证的模拟器比对系统，集成于一种基于RISC‑V架构的处理器验证系统中，该验证系统将指令生成模块、程序编译模块、模拟器模块、仿真验证模块、比对检查模块和回归管理模块联系起来，通过统一的接口和交互提高验证环境的整体效率、自动化程度和可靠性；通过集成验证系统，选择只在RTL的仿真时对关键行为和信号进行检测，然后将检查信息，比如指令执行的PC、写寄存器、写存储器等操作序列保存在不同的队列中，待仿真结束后按照跟模拟器统一好的格式输出为日志，与模拟器进行比对；相比现有方式，本发明给出的比对方式，无论是周期精确的模拟器还是功能模拟器均可无差别使用。

Description

一种基于RISC-V处理器验证的模拟器比对系统

技术领域

本发明属于处理器核验证技术领域，具体地说，是涉及一种基于RISC-V处理器验证的模拟器比对系统。

背景技术

现有的处理器验证系统对参考模型（如模拟器）的依赖较高。传统的UVM框架中使用的检测器、参考模型和计分板等组件用于进行RTL（Register Transfer Level，寄存器转换级电路）和模拟器的比对，但这种方法依赖于模拟器精确的周期建模和实时监控。然而，在项目周期有限的情况下，精确建模周期的模拟器需要投入更多的时间和人力资源，限制了验证工作的进展。

直接使用功能模拟器而不要求周期精确性的方法通常是最后一次性将RTL仿真结果与模拟器参考模型结果进行比对。然而，仅仅对比最终的寄存器或存储器中的数据往往无法有效证明验证结果比对的正确性。即使最终结果一致，由于中间过程比对被忽略，整个验证过程仍存在风险。

另一种方法是在寄存器和存储器数据变化时进行采样，然后分别在RTL和模拟器的仿真过程中保存每个寄存器变化的序列，并最后对这些变化序列进行比对。然而，一旦遇到不一致的比对结果，很难定位导致不一致的原因。即使可以按照序列变化进行重新定位，这将浪费大量的重新定位时间，影响验证效率。

对于RTL与模拟器仿真过程中，如果模拟器不支持中断调试功能，那么中断处理程序和调试自读程序中的指令流将无法在模拟器上执行，导致RTL仿真结果与模拟器仿真结果的比对不一致。如果不允许RTL仿真进入中断或调试状态，验证平台中涉及中断调试自检的机制无法与其他指令的验证同时进行，这将导致验证不具备完备性和全面性。

性能的验证往往也是验证的重要组成部分，这关乎着整个处理器的处理性能。如果使用的模拟器不是周期精确的建模，往往不能对性能进行验证。

这些问题和困难限制了现有基于RISC-V处理器验证的模拟器比对的有效性和效率。

发明内容

本发明提供一种基于RISC-V处理器验证的模拟器比对系统，用以解决上述处理器验证系统对参考模型依赖程度高、对比最终寄存器或存储器中的数据无法有效证明验证结果比对的正确性、遇到不一致的比对结果时很难定位问题位置、模拟器不支持中断调试功能时导致的比对不一致、模拟器非周期精确的建模导致不能对性能进行验证等问题。

本发明采用以下技术方案予以实现：

提出一种基于RISC-V处理器验证的模拟器比对系统，包括：

指令生成模块，为程序生成部分，生成包含随机指令流的汇编程序；其中，当验证特权功能时，在随机指令中加入以若干条存储指令结束的握手数据，以实现基于存储指令将握手数据存储到指定的签名地址；

程序编译模块，包括汇编程序所用到的编译器、连接器和反汇编器、编译所生成的结果文件资源库、以及验证系统的编译工具调用脚本；

模拟器模块，包括模拟器和模拟器输出日志文件的参考模型资源库，以及模拟器调用脚本；

仿真验证模块，包括UVM测试环境、被测对象和UVM_TEST，以及用于构建、控制和管理仿真的主脚本、项目管理脚本和Makefile；所述UVM测试环境包括UVM代理和虚拟序列器；所述UVM_TEST调用虚拟序列器动态生成用以描述不同测试场景和测试用例的随机激励；所述UVM代理包括内核输出代理，所述内核输出代理包括内核输出监测器，用于：监测被测对象实时信号变化，并将关键信号的变化信息输出到被测对象信号监视输出的RTL仿真日志文件中，以及，监测签名地址的写入操作，将写入操作的相关信息传输到UVM测试环境，以使UVM测试环境接收到签名地址上的相关信息后，执行对应特权功能的测试事务或比对操作；

比对检查模块，用于对处理器的RTL仿真日志文件与模拟器输出日志文件进行比对来检查仿真验证结果的正确性；

其中，所述内核输出代理接收和检测被测对象的信号变化，包括：

多线程处理器行为检测模块，分为多个线程子模块，用于对不同类型写寄存器和存储器行为进行监测，并将比对格式所需行为的属性记录到不同的队列中；

仿真日志输出模块，用于将不同队列中的关键属性和信息输出到RTL仿真日志中，并进行设定情况下的后处理工作；

仿真日志比对模块，用于对RTL仿真日志和模拟器输出日志进行字符串或其他数据格式的比对。

与现有技术相比，本发明的优点和积极效果是：本发明提出的基于RISC-V处理器验证的模拟器比对系统中，不再使用UVM实时比对框架，而是选择只在RTL的仿真时对关键行为和信号进行检测，然后将诸如指令执行的PC、写寄存器、写存储器等操作序列保存在不同队列中，待仿真结束后按照跟模拟器统一好的格式输出为日志，然后再与模拟器进行比对，这种比对方法无论周期精确的模拟器还是功能模拟器均可无差别使用；本发明还设计了一种需要RTL和模拟器同时遵守的格式，通过这种格式，可以对每一条指令的行为进行检查、记录和比对，基于统一的比对，从而保证仿真过程的结果正确性；通过统一的格式记录每一条指令执行的PC值和OPCODE，基于PC值可以快速定位到指令的位置以及仿真波形中对应指令执行的时间，通过将OPCODE汇编成对应的指令字符串，可以获知哪条指令出了问题，从而可快速解决问题；通过检查到进入中断处理程序和调试只读程序的时机并进行记录，然后在仿真日志的对应位置插入中断调试开始和中断调试结束的标签，在比对的过程中如果模拟器不支持中断调试功能，可以在比对时忽略中断调试开始和结束的标签之间的全部指令PC，从而不影响对其他指令行为的比对；通过在仿真日志中加入仿真开始标签和仿真结束标签，来标志比对的开始和比对的结束，同时在指令检查输入日志的过程中，加入指令执行周期数信息，并同时加入到仿真日志中，从而可以算出仿真整个过程所需要的周期数，以及指定指令序列执行所用周期数，从而完成对性能的统计和验证。

结合附图阅读本发明实施方式的详细描述后，本发明的其他特点和优点将变得更加清楚。

附图说明

图1为本发明提出的基于RISC-V架构的处理器验证系统的系统架构示意；

图2为本发明提出的UVM仿真环境的结构示意；

图3为本发明提出的基于RISC-V处理器验证的模拟器比对系统的比对方法示意。

具体实施方式

下面结合附图对本发明的具体实施方式作进一步详细的说明。

本发明提出的基于RISC-V处理器验证的模拟器比对系统，集成于一种基于RISC-V架构的处理器验证系统中，不再使用现有技术中采用UVM实时比对的方式，选择只在RTL的仿真时对关键行为和信号进行检测，然后将检查信息，比如指令执行的PC（ProgramCounter，用来表示当前欲执行的指令）、写寄存器、写存储器等操作序列保存在不同的队列中，待仿真结束后按照跟模拟器统一好的格式输出为日志，与模拟器进行比对；该比对方式，无论是周期精确的模拟器还是功能模拟器均可无差别使用。

具体的，本发明先对基于RISC-V架构的处理器验证系统进行说明。

现有的处理器验证中，包括对非特权功能的验证和特权功能的验证，其中非特权功能的验证包括：对基本指令集执行正确性的验证、对内存访问和管理的验证和对异常处理的验证；对特权功能的验证包括：中断处理、调试功能、低功耗、复位和安全保护域测试等。

现有技术中，验证特权功能依赖于模拟器，这是因为随机指令生成器的设计初衷通常是通过生成具有一定随机性的指令序列来增加测试用例的多样性，从而提高测试的覆盖率；然而，对于验证诸如中断处理的特权功能，因为这些功能通常涉及到处理器内部状态的复杂变化，如控制寄存器的写入、特权级别的切换、中断/异常的触发、安全区域内存访问权限、处理器低功耗模式切换等，这些情况的覆盖需要更为精确和细致的控制，而随机指令生成器无法在测试中充分模拟这些场景。

鉴于上述，本发明提出一种基于RISC-V架构的处理器验证系统，在给出一种将验证环境的激励生成、编译、仿真、比对和回归等组件联系起来的完善系统同时，结合对随机激励生成器的改造和握手机制，通过状态传递由验证平台自身进行中断功能点检查，不依赖特权模拟器的支持，模拟器可以不设计中断验证部分，从而降低模拟器的设计难度。

首先，本发明充分考虑特权模拟器的有限性，通过在验证平台中引入握手机制和验证平台的自我检查，实现验证平台与非特权模拟器的协同工作，这种协同工作允许在验证平台上引入灵活的、更全面的验证方法，以弥补模拟器的不足。

第二，通过在随机指令生成过程中加入握手用的程序段，本发明实现了处理器状态的实时传递，使得验证平台能够在运行时监测和比对处理器内部状态。比如，是否进入退出中断模式，中断相关控制状态寄存器的变化是否正确等。

第三，通过动态生成随机的特权功能相关的激励，验证平台能够更灵活地驱动特权功能。这种动态激励生成方法有助于覆盖更多的特权操作场景，从而提高验证的全面性。同时，不影响随机指令的运行和比对，可以和模拟器协同工作。

第四，使用UVM监视器来进行tracer功能，但是并不是每一个周期都去记录所有寄存器的变化，而是只有当处理器有写寄存器行为时，才会检查并记录修改的寄存器的值（如果硬件去做这个功能，需要更多的逻辑，占用硬件资源和面积），这样可以减少Log的大小，并且由于使用验证平台来trace，所以trace的内容和Log的格式都是可以根据情况修改的，这样可以适配不同的模拟器，使之更灵活。

第五，通过带有时间戳的历史队列，记录不同指令写同一寄存器时的执行先后顺序和是否已经写回的状态，保证被写回的寄存器中值的变化顺序正确且写回寄存器的时间和行为按预期顺序进行比对，从而与模拟的比对顺序保持一致。之所以这样做是因为，如果几条不同的指令先后写回相同的寄存器，且有时写回的值需要跟原始寄存器中的值做比较后才能决定，那么这将依赖于指令写回寄存器的时间先后顺序，和寄存器中值的变化顺序。对于非时间精确的模拟器，这几条指令都是执行后直接出结果（先执行的指令先写回寄存器）， 因此无须考虑由于执行和写回顺序不一致导致的问题。然而，处理器上执行的指令往往在执行后，需要多个周期才能出结果（这几条指令有可能后执行的指令先写回寄存器，并影响后执行指令比对的结果）。所以通过这个历史队列，可以使处理器核模拟器都按照指令写回寄存器的顺序进行对比。

基于上述，如图1和图2所示，本发明提出的处理器验证系统包括指令生成模块1、程序编译模块2、模拟器模块3、仿真验证模块4、比对检查模块5、和回归管理模块6,下面对各模块进行详细说明。

指令生成模块1，通过对RISCV-DV进行扩展和改造实现，作为验证系统的程序生成部分，负责包含随机指令流的汇编程序的生成。

为了确保处理器在收到外部激励，如中断或调试请求时，能够正确更新内部状态，同时检测所处状态和相关寄存器的正确性，本发明使用握手机制，在随机指令中加入以若干条存储指令结束的握手数据，以实现基于存储指令将握手数据存储到指定的签名地址，从而通过握手协议将信息传递给验证系统的仿真环境；在UVM测试环境中，持续监控签名地址的写入操作，表明被验证的测试对象正在执行特定的握手汇编序列，并将一些信息传输到验证系统进行进一步的分析；验证系统接收到签名地址上的信息后，执行一系列的测试事务或比对操作，从而帮助验证和比对的过程。

握手机制包括：握手数据（握手代码段）使用一小段RISC-V汇编代码生成，以一条或多条存储（store）指令结束，这些指令将握手数据存储到指定的内存地址，即签名地址（signature address）。在验证系统的UVM检测环境中，持续监控签名地址的写入操作，这将表明被验证的测试对象（DUT）正在执行特定的握手汇编序列，并将一些信息传输到验证系统以进行进一步的分析。验证系统接收到签名地址上的信息后，执行一系列的测试事务或比对操作。具体签名地址上数据的格式和含义的定义参考RISC-V DV（DesignVerification）工具。

在本发明中，引入握手数据枚举类型；首先，定义signature_type_t枚举类型，用于表示握手数据中的签名类型，包括以下几种类型：CORE_STATUS，用于向UVM测试环境传递与当前状态相关的处理器信息；TEST_RESULT，用于向UVM测试环境传递UVM仿真结果的信息；WRITE_GPR，用于向UVM测试环境发送GPR（General Purpose Register）的转储指令，随后将跟随32个写入操作，用于将寄存器x0-x31的值传递给UVM测试环境；WRITE_CSR，用于向UVM测试环境发送CSR（Control and Status Register）的写入指令，数据字的位[19:8]将作为CSR地址，紧接着的第二个写入操作将写入实际的CSR数据。

另外，还定义了core_status_t枚举类型，用于表示处理器核心的不同状态。这些状态包括已初始化（INITIALIZED）、处于调试模式（IN_DEBUG_MODE）、处于机器模式（IN_MACHINE_MODE）、处于监管模式（IN_SUPERVISOR_MODE）、处于用户模式（IN_USER_MODE）、正在处理中断请求（HANDLING_IRQ）、已完成中断处理（FINISHED_IRQ）、正在处理异常（HANDLING_EXCEPTION）、指令故障异常（INSTR_FAULT_EXCEPTION）、非法指令异常（ILLEGAL_INSTR_EXCEPTION）、加载故障异常（LOAD_FAULT_EXCEPTION）、存储故障异常（STORE_FAULT_EXCEPTION）和EBREAK异常（EBREAK_EXCEPTION）等。

本发明通过上述握手机制，能够有效地将信息从被测对象（DUT）传递到UVM测试环境，并在验证过程中进行进一步的分析和比对操作。这种握手机制的使用方式能够提高验证的可靠性和全面性，确保处理器在面对外部激励时的正确行为。

在本发明申请中，指令生成模块1是对RISCV-DV进行改造得到的，用以确保生成的随机指令流覆盖各种场景和特殊情况。为了生成复杂特殊指令，对RISCV-DV随机指令生成器进行一系列约束，包括：

（1）对于64位随机指令，RISC-V处理器体系结构通常遵循跨越两个连续寄存器数据的设计，因此要求64位指令总是使用偶数编号的寄存器。在随机指令流中，RISCV-DV已经约束了一些预留寄存器，以防止一般指令使用这些寄存器。然而，对于预留寄存器中的奇数编号，由于指令字符串构造时只使用了偶数寄存器，造成原有的约束规则对于这些奇数寄存器不再适用。为了解决这个问题，本发明对RISCV-DV进行改进，引入一个新的预留寄存器列表，当64位指令中包含对奇数寄存器的约束时，将该奇数寄存器的前一个偶数寄存器存储在一个队列中，以满足特殊预留奇数寄存器的完整约束，通过这种方式，能够生成复杂特殊的64位指令，并确保对所有预留寄存器的约束都得到满足。另外，对于随机访存指令流，其存储基地址往往通过一个预留寄存器来存储，该预留寄存器不应该在这一随机访存指令流中被再次使用，此时，如果该预留寄存器为奇数编号并且该随机访存指令流包含一些64位的指令，这些64位的指令如果只被约束为不能使用上述奇数编号的预留寄存器是不足够的，还应约束其不能使用上述奇数编号的预留寄存器的前一个偶数编号寄存器，才能满足随机访存指令流基地址固定的要求。为了解决这个问题，本发明对RISCV-DV进行改进，在生成随机访存指令流时，在确定了存储基地址的奇数编号寄存器后，将奇数编号和其前一个偶数编号寄存器都加入到预留列表中，通过这种方式，能够生成含有64位特殊指令的随机访存指令流，并确保对所有预留寄存器的约束都得到满足。

（2）对于随机访存指令流，存储基地址的寄存器通常被限制为固定地址，以控制访存指令的作用范围。然而，对于一些特殊的后增访存类指令（其执行后会直接修改存储基地址的寄存器中的值），通常用于在访存操作后对基地址进行更新或调整，从而改变了原本被约束为不变的基地址。为了解决这个问题，本系统在执行后增访存指令后，在接下来的访存指令执行之前还原被修改的寄存器中的基地址值。通过这样的改造，能够确保随机访存指令流中的访存地址作用域不会受到随意的改变，保持了约束的稳定性。这样可以有效地控制特殊后增访存指令对存储基地址的影响，确保指令生成的正确性和一致性。

（3）在不同的场景下，指令生成和生成序列可能变得复杂。在RISCV-DV中，尽管可以随机生成寄存器编号和立即数的值，但无法直接随机生成指令寄存器中操作数的值，这限制了对浮点指令输入输出特殊值的能力。为了解决这个问题，本系统通过在随机指令流中插入定向指令流的方式，当即将执行浮点指令流时，随机的插入定向指令流以初始化浮点寄存器的特殊值。这样，在生成的随机指令流中，通过定向指令流可以定制浮点寄存器的特殊值，以满足特定的测试需求。除了浮点指令流，定向指令流的方法也适用于其他场景，例如，针对特定指令集扩展或特殊的处理器功能，插入定向指令流来定制寄存器或内存的特殊值，以测试功能的正确性。这可以包括输入边界条件、异常处理、数据相关性和寄存器相关性的测试等。

本发明通过改进指令生成工具，引入定向指令流的方法，可以在生成指令序列时更灵活地控制和定制各种场景下的测试需求，以实现更全面和准确的测试目标。

程序编译模块2，包含了汇编程序所用到的编译器、连接器和反汇编器，同时包含了编译所生成文件的结果文件资源库，以及该系统设计的编译工具调用脚本，该脚本使用SHELL（UNIX操作系统的命令语言）语言编写。

本发明还设计一套完善的构建系统，能够有效地将验证环境的各个组件联系起来，包括激励生成、编译、仿真、比对和回归，并实现自动化和规范化的管理，通过统一的模块接口和交互流程，提高验证环境的整体效率、自动化程度和可靠性。

首先，整个构建系统的核心是仿真验证模块中的脚本，包括主脚本、项目管理脚本和Makefile。

主脚本（Main Script）：是整个验证流程的控制中心，它首先定义了一些关键的路径，用于指定各种文件的位置和目录结构。然后，通过定义宏（Define）来传递参数给仿真环境和测试平台，以配置不同的功能和选项。这些选项包含VCS编译和仿真的选项，以及一些必要的配置选项比如：批量回归测试还是单个用例、测试测试用例名、是否进行VCS编译、使用何种波形文件格式、是否使用模拟器对比、随机种子的大小、是否收集覆盖率等。接下来，主脚本会删除上次仿真留下的临时文件和目录，然后调用一个项目管理脚本（ProjectManagement Script）并传入测试用例的名称。项目管理脚本负责根据测试用例的分类执行相应的操作，比如编译和模拟器调用等。最后，主脚本会对仿真日志文件进行统计和打印，提取其中的通过和失败信息。

项目管理脚本（Project Management Script）：用于配置临时参数，并根据传入的测试用例名称执行不同的任务。它可以检查编译和仿真是否成功，并根据测试用例的分类执行不同的操作。例如，如果需要使用编译器，项目管理脚本会调用编译脚本来建立临时的编译环境，并将编译生成的结果文件保存在指定目录中，以避免不同测试用例之间的资源冲突。如果需要使用模拟器，它会调用模拟器的执行脚本。最后，项目管理脚本会管理仿真产生的覆盖率文件数据，并将它们保存在固定的目录中，以方便进行覆盖率的综合分析。

Makefile：是一个用于构建和管理工程的文件，它主要用于定义 VCS 编译所需的路径，如 RTL 代码文件（Filelist 路径），以及定义 VCS 编译和仿真选项。它还定义了一系列规则，如 VCS 编译规则、VCS 仿真规则、覆盖率融合规则、查看波形规则（如 Verdi）等。通过 Makefile，可以方便地进行编译、仿真和其他相关操作。

其次，程序编译和模拟器模块也有各自的脚本：编译脚本和模拟器脚本。

编译脚本（Compile Script）：主要用于配置环境变量，并根据不同的程序类型（汇编、C等）调用相应的编译命令。它会生成反汇编文件，并将编译生成的 ELF 文件转换成二进制文件，再将二进制文件转换成十六进制（HEX）文件。同时，编译脚本会保存和打印编译结果的信息，包括错误信息等。

模拟器脚本（Simulator Script）：主要用于配置环境，并根据传入的测试用例名称执行模拟器命令。它会根据预先协商好的标签解析出程序的起始比对地址和结束比对地址，然后执行模拟器，并保存和打印模拟器执行结果的信息，包括错误信息等。

再者，还有RISCV-DV指令生成器的调用脚本和回归管理脚本。

RISCV-DV指令生成器的调用脚本主要用于随机指令生成的配置参数和脚本调用。

回归脚本，为一种可以利用一键定时并行回归的脚本，用来自动化多进程回归测试流程，该脚本可以完成多个测试用例的并行回归测试，并将每个测试用例的仿真结果进行分析和汇总，生成一个日志文件，然后，将日志文件转换成可视化表格的形式，用于统计回归测试的情况，包括哪些测试用例被回归了，哪些测试用例失败，失败的原因是什么，单个测试用例的随机种子和仿真命令是什么等。通过这样的表格，可以方便地还原测试用例的现场，并进行高效的调试和分析。

另外还有RTL设计和参考模型日志文件进行比对的脚本，用于比对RTL硬件电路行为和参考模型模拟器行为是否一致。

模拟器模块3，包含模拟器系统和模拟器输出日志文件的参考模型资源库，以及模拟器调用脚本，该脚本使用SHELL语言编写。

项目管理脚本在需要使用模拟器时调用模拟器的执行脚本；模拟器脚本配置环境，根据传入的测试用例名称执行模拟器命令，它会根据预先协商好的标签解析出程序的起始比对地址和结束比对地址，然后执行模拟器，并保存和打印模拟器执行结果的信息，包括错误信息等。

仿真验证模块4，基于UVM（Universal Verification Methodology，通用的验证方法学） 框架构建，其各个子模块组件的也是继承于UVM的不同组件来实现。各个组件在UVM的UVM_ENV容器中进行连接和集成。UVM_ENV容器外还有不同的UVM_TEST，用于调用虚拟序列器动态生成用以描述不同的测试场景和测试用例的随机激励。如上面所述，仿真验证模块还包含一些脚本，用于构建控制管理整个仿真系统。其中，包括一个主脚本，整个验证流程的控制中心；一个项目管理脚本，用于配置临时参数，并根据传入的测试用例名称执行不同的任务；一个Makefile（一个用于构建和管理工程的文件），用于管理和自动化编译和运行仿真相关的任务和流程。

本发明中，仿真验证模块4由DUT（被测对象，也即处理器内核）和将围绕DUT的所有验证组件集合在一起的UVM测试环境组成，UVM测试环境集成了各个UVM_AGENT（代理）和VIRTUAL_SEQUENCER（虚拟序列器）等组件，在UVM测试环境外还有用于创建和驱动测试用例UVM_TEST。

UVM_AGENT（代理）包括：

内核输出代理，用于接收和检测被测对象的信号变化和覆盖率的收集。包括：

（1）内核输出监测器，用于检测被测对象实时信号变化，并将关键信号的变化信息输出到被测对象信号监视输出的RTL仿真日志文件中，用于后续与模拟器输出日志文件进行比对。

（2）覆盖率监视器，用于检测模块级 DUT 的关键功能信号变化，并通过功能覆盖率组进行各种覆盖点的统计，从而完成功能覆盖率统计；主要实现方法是通过SystemVerilog语言定义一些Covergroup，描述要收集的覆盖率类型和属性；然后，声明Coverpoint，定义要收集的信号或属性的覆盖率信息；在仿真过程中，使用Covergroup实例收集覆盖率数据，监控Coverpoint所依赖信号的取值变化。

（3）性能检测器，用于检测被测对象中指令从执行级到写回级的周期数，以及指令流水线冲突时流水线停顿的类型和周期数，并将相关周期数信息输出到RTL仿真日志中，用于性能的分析。

中断代理，负责中断激励的生成和中断序列的产生。包括：

（1）中断接口（interrupt interfance），用于连接被测对象的各个中断信号接口和UVM测试环境。

（2）事务（transaction）对象，用于随机生成中断激励，例如软件中断、定时器中断、外部中断、不可屏蔽中断、调试中断、异常中断等。

（3）中断序列器（sequencer），用于生成中断测试序列流，管理中断测试序列流的执行顺序并传递给中断驱动器以进行驱动；不同类型的中断可以有不同的序列，也可以将多种中断组成在一起生成复杂的随机中断序列。

（4）中断驱动器（driver），用于向被测对象接口按照一定时序逻辑发送实时中断序列，这些中断序列由中断序列器进行控制并送往中断驱动器。

存储器代理，用于对关键存储器访问的读写进行检测，还负责与被测对象的存储器进行交互，发送读写请求并检查响应。在内核验证中，其主要功能之一是对握手协议中的签名地址（signature address）进行检测，通过签名地址完成内核与UVM测试环境的握手（handshake）交互，从而对内核的状态信息进行监测。

还有其他不同类型的代理（AGENT），如总线 AGENT、JTAG（Joint Test ActionGroup，是一种用于测试和调试集成电路的标准接口）AGENT等。这些不同的AGENT负责连接和监控对应的接口，并生成相应的事务。在实现上，主要以继承第三方库提供的类来构建环境，具体需要参考相应的 VIP（Verification IP，是指在硬件设计验证过程中使用的模块化验证组件）库官方文档进行构建的编写。

虚拟序列器（VIRTUAL_SEQUENCER）将面向不同序列器（例如中断序列器）的序列群挂载到不同序列器上，用于控制测试序列的生成。它协调多个virtual sequence （虚拟序列）的执行顺序和时机，以确保测试序列按照预期顺序执行。因此，虚拟序列器可以根据测试计划和测试需求生成特定的测试序列，从而实现对验证环境的全面测试。

虚拟序列器预定义了一系列的虚拟序列（sequence），例如中断序列，用于承载不同目标序列器的序列群落，挂载到虚拟序列器上。每个测试用例（test case）都可以包含一个或多个虚拟序列，并调用其中的函数来启动和管理控制测试序列的发生。通过调用虚拟序列中的函数，测试用例可以精确地控制测试序列的生成和执行，从而验证被测设备的不同功能和场景。

UVM_TEST，在UVM测试环境外部，用于创建和驱动测试用例（test case），通过模拟被测对象的各种场景来验证被测对象的行为。UVM_TEST首先设置测试环境的初始状态，然后启动和控制一个或多个虚拟序列来模拟特定的场景。它调用虚拟序列器的特定测试序列，测试序列是一系列事务的集合，通过驱动器组件向DUT发送对应的事务，通过监视器组件捕获和分析从DUT接收到的信息，将信息转换为事务传递再给测试序列进行验证。这些组件在UVM_TEST的启动和管理下共同工作，确保了在不同操作序列下，DUT 的功能能够被全面验证。

在本发明的验证系统中，使用基础测试类（BASE_TEST）来构建、连接和执行基础、共性的测试用例。该类包含一个运行阶段（run_phase）函数，用于测试用例的主要执行过程。此外，还有一些特定功能的函数，如发送刺激信号（send_test_stimulus）函数用于向被测对象发送测试刺激信号，等待存储器事务（wait_for_memory_transaction ）函数用于等待被测对象的存储器事务，等待CSR写操作（wait_for_csr_write_operation ）函数用于等待被测对象的CSR写操作，等待核心状态（wait_core_status）函数用于等待被测对象的状态，检查下一个核心状态（check_core_next_status）函数用于检查被测对象的下一个状态是否符合预期，最终阶段（final_phase）函数用于测试结束后的清理工作等。通过使用这些函数和基础测试类，可以方便地构建和执行测试用例，并对被测对象进行全面的验证。

除此之外，还有一个测试库（TEST_LIB），它继承扩展了 BASE_TEST测试库类，根据验证计划中的功能点进行更具体的测试函数定义。每个测试用例都可以继承这个测试库类，从而实现不同测试程序与测试环境的联动。

基于上述验证系统，执行指令测试时，TEST_LIB中的“加载程序”函数初始化处理器内核指令存储器，将二进制文件加载到指定的内存地址中，其中，对于不同的内存模型，需要使用不同的加载方法进行处理，具体方法根据具体情况进行分析；然后，内核取值译码执行程序来完成指令的测试；最后，调用"等待程序执行完成"函数，通过握手（handshake）来通知验证系统全部指令执行结束。同时， UVM TEST会执行其他测试事务，两者同时进行，完成整个验证的全部过程。

UVM_TEST有很多，本发明实施例中的UVM_TEST至少包括：

1.基本指令测试；包括：

等待全面内存空间和寄存器初始化；

加载二进制文件，写入到处理器内核的指定内存地址上；

等待全部指令在被测对象中被执行；

等待过程中，每一时钟周期（每一固定单位时间）通过调用“测试完成监测事件”，来监测某一特定内存地址上是否写入了标致着仿真结束的数据信息如：0x1234567f；

如果监测到该特定内存地址上被写入了0x1234567f，则结束UVM测试环境；

2.中断调试测试，一个基本的调试中断测试函数。用于验证调试和中断处理功能的基本正确性，模拟调试事件的发生和处理过程。包括：

（1）初始化UVM测试环境并设置相关的寄存器和变量。

（2）通过调用"发送中断调试激励信号"函数发送来自虚拟序列中的中断调试激励信号，触发中断调试事件。

（3）调用"等待中断调试事件"函数等待调试事件的处理完成，确保处理器内核正确进入了中断调试模式。

（4）调用"检查中断调试事件"函数检查调试事件处理状态，验证调试事件是否被正确处理，并检查相关寄存器和变量的值是否符合预期。这里是自我检测中断事件是否正确有效的关键。

在确认调试事件处理完毕后，（5）调用"结束中断调试刺激信号的发送"函数结束调试刺激信号的发送，并等待调试事件被清除。

（6）恢复UVM测试环境，包括相关的寄存器和变量，并清理测试环境，以准备下一轮测试。

最后，（7）调用基本测试中的" check_core_next_status "函数检测处理器是否退出中断调试状态，并确保内核恢复到正常运行模式。

通过执行这些步骤，"调试中断测试"函数可以验证系统在调试事件发生时的正确响应和处理能力，以及中断调试模式的进入和退出过程是否符合预期。

3.此外，还可设计若干适应不同功能场景的库函数，例如复位、安全域、低功耗、外部存储读写等。

比对检查模块5，主要用于对处理器设计RTL（Register Transfer Level，寄存器转换级电路）仿真日志文件，与模拟器输出日志文件进行加载和比对，检查仿真验证结果的正确性。

该系统可以让模拟器执行完毕后生成固定格式的模拟器输出日志。这些日志主要记录每条指令执行后写回到 RISC-V 寄存器的情况，或者寄存器的变化序列。可以根据设计的需求选择适当的输出格式。同时，在仿真环境中也生成与模拟器一致的日志文件，最后将模拟器日志文件和处理器设计 RTL（Register Transfer Level，寄存器转换级电路） 仿真日志文件进行自动比对，以验证设计的正确性。当模拟器不支持特权功能的验证时，验证系统可通过在RTL仿真日志的对应位置插特权功能验证开始和特权功能验证结束的标签；在比对的过程中，如果模拟器不支持特权功能，在比对时忽略特权功能验证开始和特权功能验证结束标签之间的全部指令PC的比对即可，不影响非特权功能的验证比对。

基于这种RTL仿真日志与模拟器输入日志的对比方式，本发明的验证系统可以减少对参考模型（如模拟器）的依赖，无论是周期精确的模拟器，还是功能全面的模拟器，还是功能不完整（例如不支持中断调试比对）的模拟，都可以通过本发明提出的修改，并利用一套完善的日志输出和比对方案来适配本系统。

RTL仿真日志的生成、RTL仿真日志与模拟器输出日志的比对检查等内容，将结合图3在后面的内容中详述。

回归管理模块6，在处理器修改或添加新功能后重新运行一系列测试用例，以确保修改不会对已验证通过的功能产生负面影响。主要通过回归管理脚本进行大规模随机并行回归，并将回归结果进行可视化展示。

本系统支持回归验证，当RTL代码进行修改后，进行全面的功能验证，保证修改的正确性。支持大规模指令随机仿真解决回归时指令随机程度低的问题，支持多用例并行回归解决仿真效率低的问题，同时将仿真资源独立化保证回归结果正确性，回归过程规范化。最后，使用了第三方开源工具Jenkins和可视化工具Grafana，以及mysql数据库，实现了整个回归过程的自动化和可视化。

首先，为了提高回归测试的质量，扩大单次回归的指令条数，增加测试的随机性，以覆盖更全面的测试场景。一方面利用处理器的外部存储空间，将大规模指令放在外部，并通过处理器从外部存储中获取指令执行，以实现单次仿真执行大规模指令，这样做可以增加测试的随机性和覆盖度。与此同时，结合使用指令生成器来生成大规模程序，进一步增加测试的随机性和多样性。另一方面，用RISCV-DV批量生成多个程序，从而增加仿真次数来增加测试的随机化效果。

当每个测试用例的指令数量变得非常大，且测试程序和仿真次数增多时，会面临回归测试效率的问题。为了解决这个问题，本发明充分利用仿真环境所在系统或服务器的硬件资源，实现并行执行多个测试用例的回归测试。基本思路是通过一次编译生成simv仿真文件，并利用这个仿真文件进行多次并行的回归仿真，以最大限度地节省编译和仿真时间，并充分利用硬件资源。在进行多进程的并行仿真时，需要确保构建系统能够将单次仿真的结果文件（如程序、hex文件、比对文件、日志文件等）相互隔离开，以保证多进程仿真过程中验证的正确性。

最后，为了使回归测试过程流程化和规范化，并减少重复工作，本发明利用一键定时并行回归的脚本来自动化多进程回归测试流程。该脚本可以完成多个测试用例的并行回归测试，并将每个测试用例的仿真结果进行分析和汇总，生成一个日志文件。然后，可以将日志文件转换成可视化表格的形式，用于统计回归测试的情况，包括哪些测试用例被回归了，哪些测试用例失败，失败的原因是什么，单个测试用例的随机种子和仿真命令是什么等。通过这样的表格，可以方便地还原测试用例的现场，并进行高效的调试和分析。

此外，通过 Jenkins工具以及Pipline插件来支持回归测试管理的自动化和持续集成。Jenkins提供了自动化构建、测试和部署回归流程的功能。通过配置JenkinsPipeline，可以定义和管理回归测试的整个流程。在Pipeline中，可以包含各种阶段，如构建、测试、部署等。通过编写Pipeline脚本，可以将回归测试的各个步骤自动化执行，并与版本控制系统（如Git）集成，以便在代码提交后自动触发回归测试流程。同时，使用grafana这样的可视化工具，可以将回归测试结果以图表形式展示，使得回归测试的数据更加可视化和易于理解。grafana可以与Jenkins集成，以实时更新并展示回归测试的结果和趋势。此外，为了保存回归测试的结果和相关数据，可以使用MySQL数据库或其他适合的数据库。通过将回归测试结果存储在数据库中，可以进行历史记录和数据分析，以及与其他团队成员共享和访问。

本发明上述提出的基于RISC-V架构的处理器验证系统，按照如下步骤实施验证：

步骤1：整个系统的启动开始于指令生成模块，通过激励生成脚本或者回归管理脚本，启动指令生成模块的运作。之后，激励生成脚本或者回归管理脚本的配置参数会传递到RISCV-DV的指令生成脚本中，从而根据仿真测试用例名、指令生成测试用例名、随机种子、生成汇编程序数量、每个汇编程序中指令的条数等一系列参数来生成一个或多个汇编程序。

步骤2：汇编程序生成后放置在程序编译模块的资源库中，仿真验证模块中的主脚本、项目管理脚本解析传入的参数和测试用例名称，并开始一系列构建工作，之后调用程序编译模块中的编译脚本执行编译器，对汇编文件进行编译、链接、反汇编、转二进制文件等一系列操作，最后将结果保存在独立的编译模块结果资源库中。

步骤3：编译结果资源库中的二进制文件，被模拟器模块中的脚本和仿真验证模块中的脚本同时调用，传人各自的模块中。模拟器在模拟器脚本的作用下开始模拟器的仿真，并输出模拟器输出日志文件；同时，仿真验证模块的Makefile也开始构建，并开始执行VCS编译和仿真命令；当仿真开始后，UVM测试环境外的UVM_TEST根据不同的测试用例调用不同的测试函数；对于指令的测试，先调用二进制文件加载函数，将二进制文件写入到处理器内核的指定内存地址上，同时将没有程序存放的地址和寄存器进行初始化，防止处理器运行时读取到没有初始化的不定态数据。

步骤4：在处理器内核仿真过程中，UVM_TEST直接作用于UVM测试环境中的各个组件，从而完成不同类型的功能测试。UVM测试环境实时与处理器内核进行交互，进行仿真验证，以及实时监测内核关键寄存器的信号变化，并记录成日志导出。同时，VCS编译仿真的日志文件，也会随之输出。在此过程中，如果使用回归管理脚本，进行回归验证，会批量进行测试用例的仿真和执行，并输出对应的仿真日志。

仿真的过程和实施方案将结合图2在下面的内容中详述。

步骤5：比对模块中的比对脚本加载模拟器输出日志和处理器的RTL仿真日志，然后进行比对，最后输出报告。该报告决定了仿真验证结果的成功与否。如果是回归验证，该报告中的关键信息被保存在数据库中。

如图2所示，在UVM测试环境中，首先会根据不同的UVM_TEST执行不同的测试或生成不同的测试序列。以中断测试为例，中断测试TEST会启动UVM测试环境中虚拟序列器中的序列生成任务，使中断代理中的中断序列器生成相关的随机序列，这些随机序列会在虚拟序列器中先被虚拟任务处理，然后被送到中断代理中的中断驱动器里被相关的任务所驱动，从而将随机序列直接作用于被测对象的中断信号接口上，从而完成处理器中断的随机生成。

处理器中的相关模块收到接口上的中断请求后开始进行中断相关处理，此时，内核输出代理中的监视器开始对处理器的行为（比如中断控制寄存器）的变化进行实时监控并将变化序列保存在相关序列中，直到仿真结束，再把队列中的变化序列转换成日志格式化文件输出，用于比对模块的比对。与此同时，内核输出代理中的覆盖率监视器开始收集内核仿真的覆盖率信息。

在内核仿真过程中，UVM_TEST库中的仿真结束检测任务会一直监视用于存储仿真结束状态的签名地址。一旦监测到内核进入仿真结束状态，整个仿真验证将强制结束。此时，会输出UVM仿真的日志文件、监视器用于比对的日志文件以及含有覆盖率信息的数据库文件。

下面基于上述给出的基于RISC-V架构的处理器验证系统，针对RISC-V处理器验证的模拟器比对系统进行说明。

本发明提出的比对系统，结合上述基于RISC-V架构的处理器验证系统中的内核输出代理的内核输出监测器实现，如图3所示，其被划分为三个模块：

（1）多线程处理器行为检测模块，根据处理器架构的实现不同分为多个线程子模块，用于对不同类型写寄存器和存储器行为的监测，并将比对格式所需行为的属性记录到不同的队列中。

（2）仿真日志输出模块，用于将不同队列中的关键属性和信息输出到仿真日志中，同时会进行特殊情况下的后处理工作，如：中断调试标签的插入、不同模块写同一类型寄存器时的行为顺序调整以及特殊情况下写寄存器行为的忽略等。

（3）仿真日志比对模块，即可以在监测器中实现，也可以在UVM平台之外实现，其作用主要是对RTL和模拟器的仿真输出日志进行字符串的比对。

在多线程处理器行为检测模块中，包括如下多个子线程模块：

1.有效指令的监测和记录线程，负责有效指令的监测和记录。首先，通过仿真脚本传入的参数获取仿真开始和仿真结束的PC值，并等待复位信号；在每个时钟上升沿开始时获取当前周期译码模块的PC值，并判断PC值是否位于仿真开始和仿真结束的方位之内，若是则执行下述任务。

2.PC监测线程，首先，判断当前PC所译码的指令是否有效，这需要结合处理器架构的具体规则进行判断，例如，判断译码模块的指令是否有效，是否存在流水线的停顿或刷新，是否存在同步或异步跳转，以及是否存在中断跳转等条件。然后，由于一条指令的PC值会保持一段时间，因此，每个周期判断上一周期的PC值是否与当前周期的PC值相同，只有当它们不相同时，才可以将该PC值对应的指令看作是一条有效指令；接下来，将有效指令的PC值放入一个队列中，这样，该PC队列将记录所有有效指令的PC序列，并可以在后续的处理中使用。

3.定点计算模块写定点寄存器监测线程，在仿真开始到结束阶段的每个周期去判断定点计算模块写回寄存器的使能信号（o_ixu_xrf_wdata_wb这个信号是被测对象里的信号名字，不同处理器不一样）是否拉高，如果拉高并且写回的寄存器地址不是0号寄存器（0号寄存器通常只读），那么就获取当前周期定点计算模块中写回流水级的PC、指令编码OPCODE、写寄存器地址和写寄存器数据。

注意，此处写回流水级的PC和指令编码，要区分与指令取指译码时的PC和指令编码，往往处理器的RTL代码里无需实现。这里为了本比对系统可以获取到写回时所在流水级指令的PC和OPCODE，可以与相关设计者进行协商，从RTL代码中译码模块中获取相关译码级信号输入到执行级或写回级模块中，进行逻辑处理变为执行级或写回级的输出信号。同时为了不影响RTL原本设计，可以通过Verilog define宏定义的方式，将这些用于验证的PC和OPCODE进行条件编译，从而即满足了验证系统需要，有添加冗余的信号和逻辑。之后，该线程把获取到的流水级的PC、指令编码OPCODE、写寄存器地址和写寄存器数据信息放入到一个关联数组队列的数据结构中保存。该关联数组队列的数据结构是一个队列，队列中的每个元素key（键值）是一个32bit类型的pc值，key所对应的value（值）是一个子队列，该子队列是一个多维数组，多维数组中的每一维度的元素存放指令编码opcode、写寄存器地址和写寄存器数据等32bit类型的信息。这里之所以一个key对应的是一个队列的原因，是同一个指令或pc在整个处理器执行过程中会出现多次，由于分支跳转和硬件循环等方式，通过队列可以保存不同时刻，同一PC多次出现时各自的写寄存器信息。通过这种数据结果，定点计算模块写定点寄存器监测线程完成了所有定点计算模块写定点寄存器的信息。这种方式在后面的线程里也频繁使用。

4.定点计算模块写定点寄存器对监测线程，该线程的实现与定点计算模块写定点寄存器监测线程一致，不同的是该线程监测的是64位的定点写回结果，需要写回寄存器对（两个连续的寄存器）。因此在监测条件上需要判断64位写回使能信号（o_ixu_xrf_pair_index）是否拉高，并且在保存记录写行为信息时，需要同时记录两个寄存器的写回行为。

5.读写访存模块写定点寄存器监测线程：该线程的实现与定点计算模块写定点寄存器监测线程一致，不同之处在于监测条件上需要判断访存写回使能信号（o_lsu_xrf_we_wb）是否拉高。另外对于后增访存指令，往往不在流水线wb写回级写回，而是在ex执行级写回，因此，往往监测条件上需要判断访存写回使能信号（o_lsu_xrf_we_ex）是否拉高。

6.读写访存模块写浮点寄存器监测线程：该线程的实现与读写访存模块写定点寄存器监线程实现一致，不同之处在于该线程监测浮点寄存器的写回，需要根据浮点写回的使能信号（o_lsu_frf_we_wb）进行条件判断。

7.浮点计算模块写浮点寄存器监测线程，该线程的实现与定点计算模块写定点寄存器监线程实现一致。不同之处在于该线程监测需要根据浮点计算模块中浮点写回的使能信号（o_fxu_frf_we_wb）进行条件判断。

8.浮点计算模块写定点寄存器对监测线程，该线程的实现与定点计算模块写定点寄存器监线程实现一致。不同之处在于该线程监测需要根据浮点计算模块中定点写回的使能信号（o_fxu_xrf_we_wb）进行条件判断。

9.控制状态寄存器模块写定点监测线程，该线程的实现与定点计算模块写定点寄存器监线程实现一致。不同之处在于该线程监测需要根据控制状态寄存器模块中定点写回的使能信号（o_csr_xrf_we_wb）进行条件判断。

10.浮点计算模块写FCSR监测线程，该线程用于监测浮点计算时，控制状态寄存器FCSR的写行为。该线程中与其他线程不同，只需要在关联数组队列保存FCSR寄存器地址和一个时间戳（计数器），这个时间戳用于记录指令执行的时间点。然后该线程还需要一个能够保存历史记录的关联数组队列，其结构与前面的关联数组一致，但多了一个维度的数组用于保存该指令是否已经写回的信息队列。这样实现是因为，FCSR不仅通过浮点计算模块写入数据，还会通过控制状态寄存器模块进行写入数据的操作，因此其写入规则和优先级需要根据硬件设计文档具体情况具体分析。在本系统中，当不同模块写FCSR时，需要根据FCSR本来的值进行判断和逻辑运算来得到最终真实写入的结果，这表示需要知道哪个模块先写了FCSR，因此通过一个时间戳记录指令执行的循序，在后处理中进行FCSR写操作的进一步处理，具体方法在仿真日志输出模块中进行说明。

11.控制状态寄存器写FCSR监测线程，其实现与浮点计算模块写FCSR监测线程一致，也需要有一个历史关联数组队列。具体原因上面已解释。这里不同于之前的是，控制状态寄存器的指令分为三种csrrw（写csr）、csrrc（将对应比特位的数据清0）、csrrs（将对应比特位的数据置1）。因此需要根据三种情况的写使能条件对线程监控条件进行对应改变。

12.控制状态寄存器写CSR监测线程：该线程由于不考虑FCSR，因此不需要做特殊处理，只需要分辨不同类型csr寄存器地址，然后按照条件进行监测即可。

13.控制状态寄存器写特权CSR监测线程，主要监测特权CSR如：MSTATUS、MCAUSE、MIE等CSR的写行为。需要根据设计中对特权的写条件进行具体情况具体分析。

14. 扩展寄存器模块的检查线程：用于扩展寄存器的写行为监测。具体方法根据扩展寄存器的实现来灵活改变。

15.写内存模块的检查线程：用于内存的写行为监测。具体方法根据硬件设计内存的实现来灵活改变。

仿真日志输出模块用于将不同队列中的关键属性和信息输出到仿真日志中，同时会进行特殊情况下的后处理工作，如：中断调试标签的插入、不同模块写同一类型寄存器时的行为顺序调整以及特殊情况下自定义写寄存器行为的忽略等。

首先，仿真日志输出模块对浮点计算模块写FCSR监测线程和的控制状态寄存器写FCSR监测线程的历史关联数组队列进行处理和排序。具体包括：

首先，定义一个当前临时变量用于保存当前处理到的FCSR中的值。然后，当两个历史队列都不为空时，如果浮点计算模块写FCSR监测线程中的历史时间戳大于控制状态寄存器写FCSR监测线程中的历史时间戳，那么就浮点计算模块写FCSR监测线程中历史保留的写FCSR值与当前临时变量中的值进行或操作；这是因为RISCV处理器实现时，浮点写FCSR的值往往保留FCSR原本的值和将要写入的值中较大的值（此处规则可根据硬件实现自行改变）。然后，把上述或运算的结果作为实际写回的值记录到浮点计算模块写FCSR监测线程中关联数组队列中，同时把当前临时变量的值改为上述或运算的结果。如果控制状态寄存器写FCSR监测线程中的历史时间戳大于浮点计算模块写FCSR监测线程中的历史时间戳，那么就直接把控制状态寄存器写FCSR监测线程中历史保留的写FCSR值作为实际写回的值记录到状态控制寄存器模块写FCSR监测线程中关联数组队列中。然后进入下次历史关联数组队列的时间戳比较。最后，两个模块中历史队列如果有一个为空，就将不为空的那个模块队列剩下的元素按照同样的规则作为实际写回值写回到那个模块的关联数组队列中。从而完成了对FCSR写行为的重新排序。

其次，需要将不同队列中的关键属性和信息输出到RTL仿真日志中，包括：先遍历PC监测线程中所保存的PC队列，把队列中每个元素作为一个KEY键值，首先把这个PC、对应的指令编码OPCODE以及周期计数作为字符串输出到日志中，然后使用这个键值去匹配不同线程中保存的关联数组队列中的元素。每当KEY在每个关联数组中找到了对应的元素，就将这个元素数组队列中队首的元素数组的每一个维度的值以固定的格式组成为字符串，然后输出到日志中，同时将这个元素数组从元素数组队列队首删除。另外，使用KEY键值去查找各个线程中保存的关联数组队列时，需要按照一定的先后顺序，该顺序需要与处理器实际执行的有效指令PC保持一致。

再者，如果存在特殊情况，比如零号定点寄存器不能写、有些控制状态寄存器不需要比对等情况，可以在日志输出的时候加入一些条件判断，忽略掉满足条件的信息，来满足特殊验证比对的要求。

仿真比对模块主要是对RTL仿真日志和模拟器输出日志进行字符串的比对，包括：首先，分别加载RTL输出日志和模拟器的输出日志，然后分别对两个文件进行同样的处理。以一个文件为例，首先获取含有PC值的那一行字符串，把其中的PC值提取作为一个KEY键值，将此KEY值加入到一个KEY值队列中，并将这一行字符串保存在一个字符串类型队列中。然后继续遍历日志文件，把变量到所有字符串信息保存在之前的字符串队列中，直到遍历到下一个含有PC值的那一行字符串。然后把这个字符串队列作为以PC值为KEY的关联数组，加入到这个PC所关联的数组队列中。然后开始解析第二KEY值和其关联的字符串队列，依次类推。在最终对比的过程中，将其中一个日志创建的KEY值队列中的每个KEY作为比对单位，然后从头到尾遍历KEY值队列。当以某一个KEY作为比对单位时，先比较该key值关联的两个日志文件所创建的字符串关联数组队列的长度是否一致，如果不一致说明RTL和模拟器仿真所执行的PC不一致，说明执行的指令不一致，需要报错。然后如果同一key关联的字符串关联数组队列长度一致。再去对字符串关联数组队列中的每个子元素队列的长度进行比较，如果长度不一致，说明这条指令执行时，所写寄存器和存储器的行为不一致，需要报错。如果长度一致，再看每个子元素队列中的每个字符串元素的值相不相同看，如果不相同，需要报错。根据此流程可以完成RTL和模拟器仿真输出的日志文件的比对。

针对现有技术中仅对比最终的寄存器或存储器中的数据往往无法有效证明验证结果比对的正确性，中间过程比对被忽略，整个验证过程仍存在风险的问题，本发明提出的模拟器比对系统设置了一种统一的有效的比对格式，需要RTL和模拟器同时遵守这种格式。这种格式包含了指令执行的PC值，指令的opcode（指令操作码），写寄存器的类型如：定点寄存器、浮点寄存器、控制状态寄存器等，写寄存器的编号或地址，写寄存器的值，写寄存器时的当前周期数。通过这种格式，可以对每一条指令的行为进行检查、记录和比对，从而保证了仿真中间过程的结果正确性。

下面是一个具体的例子：

对于指令

add x1，x2，x3；

这条指令的作用是将x2寄存器中的值与x3中的值相加，然后将计算结果写回到x1中。

假设这条指令存储在十六进制0x100000地址上，那么其PC值为0x100000。

这条指令的执行过程会被定点写回定点寄存器线程所监测，该线程会将PC值0x100000作为KEY，KEY对应的关联数组队列记作：IXU_XRF_LIST,那么IXU_XRF_LIST[0x100000][$]代表的是与KEY 0x100000关联且长度为无限长的队列。IXU_XRF_LIST[0x100000][$][2]表示，该队列中的每个元素是个数组，每个数组又包含两个维度的元素，这两个元素可以分别存储写寄存器的地址，写寄存器的值等信息。即IXU_XRF_LIST[0x100000][0][0]=1，表示以0x100000为KEY的关联数组队列中的第一个元素（指令第一次出现），这个元素是一个数组，这个数组的第一元素是1（代表1号寄存器）。IXU_XRF_LIST[0x100000][0][1]=0x8，表示以0x100000为KEY的关联数组队列中的第一个元素，这个元素是一个数组，这个数组的第二元素是0x8（代表1号寄存器写回结果是0x8）。

最终在日志中，该指令的输出格式为：

第一行：PC：0x100000，OPCODE:0x003100b3, CYCLE:100

第二行：Write int，index：1，value：0x8

针对一旦遇到不一致的比对结果，很难定位导致不一致的原因，即使可以按照序列变化进行重新定位，但会浪费大量的重新定位时间而影响验证效率的问题，本系统通过上述统一的格式，记录了每一条指令执行的PC值和OPCODE。通过PC值，可以快速定位到指令的位置，以及仿真波形中对应指令执行的时间点。通过将OPCODE反汇编成对应的指令字符串，可以轻而易举地知道是哪条指令出了问题，从而可以快速解决问题。

如：PC：0x100000，OPCODE:0x003100b3, CYCLE:100；

其中，PC对应的地址是0x100000，OPCODE所对应的汇编指令是：add x1，x2，x3，当前周期数是:100。通过这种格式可以快速定位问题指令是什么，问题位置在哪里。

针对如果模拟器不支持中断调试功能，那么中断处理程序和调试只读程序中的指令流将无法在模拟器上执行，导致RTL仿真结果与模拟器仿真结果的比对不一致，将会导致验证不具备完备性和全面性的问题，本系统在检查到进入中断处理程序和调试只读程序的时进行记录，然后在仿真日志的对应位置插入中断调试开始和中断调试结束的标签。最后，在比对的过程中，如果模拟器不支持中断调试功能，可以在比对时忽略中断调试开始和中断调试结束的标签之间的全部指令PC，从而不影响对其他指令行为的比对。

此功能的实现，需要在PC监测线程中加入额外的逻辑和监测。首先，需要建立如上所述格式的关联数组队列IRQ_START_MAP，用来保存与PC关联的中断信息。当获取有效PC后，对中断或调试的跳转信号进行监测，如果当前没有中断跳转，需要将一个空队列插入到跟当前PC相关联的关联数组IRQ_START_MAP队列中。如果当前有中断跳转，要根据模拟器支持中断的情况进行具体情况具体分析。比如，如果模拟器支持异常中断对比，但是不支持其他中断的对比，那么需要通过MCAUSE控制状态寄存器最高位进行判断，区分出当前中断是否需要忽略对比。如果需要忽略对比，需要将一个字符串标签“<start_irq>”插入到IRQ_START_MAP队列中。同时，不仅需要监测中断开始的时机还要知道中断结束的时机。与IRQ_START_MAP相同，需要创建一个IRQ_END_MAP关联数组队列。如果当前检测到没有MRET、MNRET或者DRET指令执行，表明当前中断处理程序没有结束，需要将一个空队列插入到跟当前PC相关联的关联数组IRQ_END_MAP队列中。如果检测到当前有MRET、MNRET或者DRET指令执行，表明当前中断处理程序结束。这时，需要将一个字符串标签“<end_irq>”插入到IRQ_START_MAP队列中。当进入仿真日志输出模块时，需要优先判断当前PC是否在IRQ_START_MAP有关联的元素，如果有需要先将<start_irq>输出到日志文件中。然后，再判断当前PC是否在IRQ_END_MAP有关联的元素，如果有需要将<end_irq>输出到日志文件中。然后再进行仿真日志输出模块常规流程。在进入仿真比对模块后，首先设置一个flag，如果日志文件行出现了<start_irq>，就将flag置1，表明从当前时刻往后，只要flag不清0，就不进行比对。直到日志文件行出现了<end_irq>,才可以重新开始比对。

针对如果使用的模拟器不是周期精确的建模，往往不能对性能进行验证的问题，本系统通过在仿真日志中加入仿真开始标签和仿真结束标签，来标志比对的开始和比对的结束。同时在指令检查输出日志的过程中，加入了指令执行时周期数的信息，并同时加入到了仿真日志中。从而可以算出仿真整个过程所需要的周期数，以及指定指令序列执行所用周期数，从而完成对性能的统计和验证。

前面已说明了检测仿真开始标签和仿真结束标签的方法，对于周期计数，只需要在多线程处理器行为监测模块一开始，在每个时钟上升沿时，将周期计数器加1即可。然后，在检测有效PC时，同样通过一个与PC关联的关联数组，保存当前周期计数的值并加入队列即可。最后在PC字符串输出时，将周期计数随之一起输出到日志文件中。

以一组指令序列为例，说明本发明给出的基于RISC-V处理器验证的模拟器比对系统，具体实施方式和流程。

指令流如下：

_start: //开始标签

0x100000: add x1，x2，x3

0x100004: fnmadd.s ft1,ft2,ft3,ft4,rdn

0x100008: csrw FCSR，x1

//中断触发

0x10000c: add x1，x2，x3

test_done: //结束标签

0x100010: add x1，x2，x3

（其中fnmadd.s ft1,ft2,ft3,ft4,rdn指令取址时间点比csrw FCSR，x1早，但是写回fcsr的时间点比csrw FCSR，x1晚）

步骤一：

程序编译加载到处理器执行指令过程与上述一种基于RISC-V架构的处理器验证系统一致。

步骤二：

由于_start标签开始地址是0x1000000，test_done标签的开始地址是0x100010。因此在PC监测线程中，只有当前周期的PC为0x100000时才开始监测，并且当PC为0x100010时结束监测。之后，PC队列中依次入队的PC为：0x100000、0x100004、0x100008、0x10000c。同时，由于有一个中断在0x10000c之前触发，因此IRQ_START_MAP里的元素为：IRQ_START_MAP[0x100000]=NULL、

IRQ_START_MAP[0x100004]=NULL、

IRQ_START_MAP[0x100008]=NULL、

IRQ_START_MAP[0x10000c]=”<start_irq>”、

IRQ_START_MAP[0x10000c]=NULL

注意：IRQ_START_MAP[0x10000c]由于是存储中断标志，它用到了0x10000c这个KEY，但是他不会进行有效的写行为输出，当<start_irq>被输出到日志中时，IRQ_START_MAP[0x10000c]也会在队列中被清除。

与其相似，IRQ_START_MAP里的元素为：

IRQ_END_MAP[0x100000]=NULL、

IRQ_END_MAP[0x100004]=NULL、

IRQ_END_MAP[0x100008]=NULL、

IRQ_END_MAP[0xXXXXXX]=”<end_irq>”、

IRQ_END_MAP[0x10000c]=NULL

注意，此处0xXXXXXX为一个不确定的PC值，它根据中断处理程序中mret指令的地址来决定。

步骤三：

接下来，各个处理器行为监测模块中的线程开始对处理器行为进行监测。

add x1，x2，x3是定点计算模块写定点寄存器，因此在计算模块写定点寄存器线程中被监测，监测后的队列为IXU_XRF_MAP：

IXU_XRF_MAP[0x100000][0]=1；(写回一号寄存器)

IXU_XRF_MAP[0x100000][1]=0x8；（假设x1写回值为0x8）

fnmadd.s ft1,ft2,ft3,ft4,rdn是浮点计算模块写浮点寄存器，因此在浮点计算模块写浮点寄存器线程中被监测，监测后的队列为FXU_FRF_MAP：

FXU_FRF_MAP[0x100004][0]=1；(写回一号寄存器)

FXU_FRF_MAP[0x100004][1]=0xf；（假设ft1写回值为0xf）

同时，fnmadd.s ft1,ft2,ft3,ft4,rdn是浮点计算模块写FCSR寄存器，因此在浮点计算模块写FCSR线程中被监测，监测后的队列为FXU_FCSR_MAP：

FXU_FCSR_MAP[0x100004][0]=0x3(写回3号寄存器)

FXU_FCSR_MAP[0x100004][1]=NULL（未赋值）

FXU_FCSR_MAP[0x100004][2]=0(是否已经写回)

同时记录历史队列FXU_FCSR_HISTORY:

FXU_FCSR_HISTORY[0x100004][0]=0xf(假设fcsr写回值为0xf)

FXU_FCSR_HISTORY[0x100004][1]=2(时间戳)

csrw FCSR，x1是状态控制寄存器模块写FCSR，因此在状态控制寄存器模块写FCSR线程中被监测，监测后的队列为CSR_FCSR_MAP：

CSR_FCSR_MAP[0x100008][0]=0x3(写回3号寄存器)

CSR_FCSR_MAP[0x100008][1]=NULL（未赋值）

CSR_FCSR_MAP[0x100008][2]=0(是否已经写回)

同时记录历史队列CSR_FCSR_HISTORY:

CSR_FCSR_HISTORY[0x100008][0]=0xa(假设fcsr写回值为0xa)

CSR_FCSR_HISTORY[0x100008][1]=1(时间戳，比fnmadd.s ft1,ft2,ft3,ft4,rd写回的早)

add x1，x2，x3是定点计算模块写定点寄存器，因此在计算模块写定点寄存器线程中被监测，监测后的队列为IXU_XRF_MAP：

IXU_XRF_MAP[0x10000c][0]=1；(写回一号寄存器)

IXU_XRF_MAP[0x10000c][1]=0xa；（假设x1写回值为0xa）

步骤四：

对CSR_FCSR_MAP和FXU_FCSR_MAP进行重新排列。

进行判断发现CSR_FCSR_HISTORY的size大于0且FXU_FCSR_HISTORY的size大于0，于是比较CSR_FCSR_HISTORY中第一个元素的时间戳即CSR_FCSR_HISTORY[0x100008][1],和FXU_FCSR_HISTORY中第一个元素的时间戳即FXU_FCSR_HISTORY[0x100004][1]。发现CSR_FCSR_HISTORY[0x100008][1]大于FXU_FCSR_HISTORY[0x100004][1]，因此如果CSR_FCSR_MAP[0x100008][2]为0就先写回CSR模块的FCSR：

CSR_FCSR_MAP[0x100008][1]= 0xa

CSR_FCSR_MAP[0x100008][2]= 1(已写回)

FCSR_TEMP = 0xa（记录当前FCSR）

将CSR_FCSR_HISTORY队首元素排除。

继续判断，发现CSR_FCSR_HISTORY的size为0，

于是对FXU_FCSR_HISTORY进行操作。

FXU_FCSR_MAP[0x100004][1]= 0xf（0xa 按位或上 0xf）

FXU_FCSR_MAP[0x100004][2]= 1(已写回)

FCSR_TEMP = 0xf（记录当前FCSR）

将FXU_FCSR_HISTORY队首元素排除。

步骤五：

遍历PC队列。

当PC为100000时，打印：

PC：100000，OPCODE:0x003100b3, CYCLE:1

IXU_XRF_MAP有关联元素，打印：

Wirte int， index：1，value：0x8

当PC为100004时，打印：

PC：100004，OPCODE: 0x5E81406F, CYCLE:2

FXU_FRF_MAP有关联元素，打印：

Wirte float， index：1，value：0xf

FXU_FCSR_MAP有关联元素，打印：

Wirte csr， index：3，value：0xf

PC：100008，OPCODE: 0x73A12073, CYCLE:3

CSR_FCSR_MAP有关联元素，打印：

Wirte csr， index：3，value：0xa

进入中断

<irq_start>

…（假设10个周期）

<irq_end>

退出中断

PC：10000c，OPCODE: 0x00300333, CYCLE:13

IXU_XRF_MAP有关联元素，打印：

Wirte int， index：1，value：0xa

步骤六：

对RTL仿真日志和模拟器输入日志进行比对，详细步骤在仿真日志比对模块中已经详述。

应该指出的是，上述说明并非是对本发明的限制，本发明也并不仅限于上述举例，本技术领域的普通技术人员在本发明的实质范围内所做出的变化、改型、添加或替换，也应属于本发明的保护范围。

Claims (10)

1.一种基于RISC-V处理器验证的模拟器比对系统，其特征在于，包括：

指令生成模块，为程序生成部分，生成包含随机指令流的汇编程序；其中，当验证特权功能时，在随机指令中加入以若干条存储指令结束的握手数据，以实现基于存储指令将握手数据存储到指定的签名地址；

程序编译模块，包括汇编程序所用到的编译器、连接器和反汇编器、编译所生成的结果文件资源库、以及验证系统的编译工具调用脚本；

模拟器模块，包括模拟器和模拟器输出日志文件的参考模型资源库，以及模拟器调用脚本；

仿真验证模块，包括UVM测试环境、被测对象和UVM_TEST，以及用于构建、控制和管理仿真的主脚本、项目管理脚本和Makefile；所述UVM测试环境包括UVM代理和虚拟序列器；所述UVM_TEST调用虚拟序列器动态生成用以描述不同测试场景和测试用例的随机激励；所述UVM代理包括内核输出代理，所述内核输出代理包括内核输出监测器，用于：监测被测对象实时信号变化，并将关键信号的变化信息输出到被测对象信号监视输出的RTL仿真日志文件中，以及，监测签名地址的写入操作，将写入操作的相关信息传输到UVM测试环境，以使UVM测试环境接收到签名地址上的相关信息后，执行对应特权功能的测试事务或比对操作；

比对检查模块，用于对处理器的RTL仿真日志文件与模拟器输出日志文件进行比对来检查仿真验证结果的正确性；

其中，所述内核输出代理接收和检测被测对象的信号变化，包括：

多线程处理器行为检测模块，分为多个线程子模块，用于对不同类型写寄存器和存储器行为进行监测，并将比对格式所需行为的属性记录到不同的队列中；

仿真日志输出模块，用于将不同队列中的关键属性和信息输出到RTL仿真日志中，并进行设定情况下的后处理工作；

仿真日志比对模块，用于对RTL仿真日志和模拟器输出日志进行字符串或其他数据格式的比对。

2.根据权利要求1所述的基于RISC-V处理器验证的模拟器比对系统，其特征在于，所述多个线程子模块包括：

有效指令的监测和记录线程，通过仿真脚本传入的参数获取仿真开始和仿真结束的PC值，并等待复位信号；在每个时钟上升沿开始时获取当前周期译码模块的PC值，如果PC值为开始仿真的PC参数值，才开始进行PC的检测，直到PC值为结束仿真的PC参数值，对PC值的监测才停止，当开始进行PC检测则执行下述任务；

PC监测线程，判断当前PC所译码的指令是否有效，以及判断上一周期的PC值是否与当前周期的PC值相同，在不相同时将当前PC值对应的指令判断成为有效指令，并将有效指令的PC值放入一个队列中；

定点计算模块写定点寄存器监测线程，在仿真开始到结束阶段的每个周期判断定点计算模块写回寄存器的32位写回使能信号是否拉高；在32位写回使能信号拉高并且写回的寄存器地址不是0号只读寄存器时，从寄存器地址不是0号的寄存器获取当前周期定点计算模块中写回流水级的PC、指令编码、写寄存器地址和写寄存器数据；把获取到的流水级的PC、指令编码、写寄存器地址和写寄存器数据放入到一个关联数组队列的数据结构中；

定点计算模块写定点寄存器对监测线程，在仿真开始到结束阶段的每个周期判断定点计算模块写回寄存器的64位写回使能信号是否拉高；在64位写回使能拉高并且写回的寄存器地址不是0号只读寄存器时，从寄存器地址不是0号的寄存器获取当前周期定点计算模块中写回流水级的PC、指令编码、写寄存器地址和写寄存器数据；把获取到的流水级的PC、指令编码、写寄存器地址和写寄存器数据放入到一个关联数组队列的数据结构中；

读写访存模块写定点寄存器监测线程，与所述定点计算模块写定点寄存器监视线程一致，监测条件上判断访存写回使能信号是否拉高；

读写访存模块写浮点寄存器监测线程，与所述读写访存模块写定点寄存器监测线程一致，监测浮点寄存器的写回，根据浮点写回的使能信号进行条件判断；

浮点计算模块写浮点寄存器监测线程，与所述定点寄存器监测线程一致，根据浮点计算模块中浮点写回的使能信号进行条件判断；

浮点计算模块写定点寄存器对监测线程，与所述定点寄存器对监测线程一致，根据浮点计算模块中定点写回的使能信号进行条件判断；

控制状态寄存器模块写定点监测线程，与所述定点计算模块写定点寄存器监测线程一致，根据控制状态寄存器中定点写回的使能信号进行条件判断；

浮点计算模块写FCSR监测线程，用于监测浮点计算时，控制状态寄存器FCSR的写行为；在关联数组队列保存FCSR寄存器地址和一个时间戳，所述时间戳用于记录指令执行的时间点；包括一个保存历史记录的关联数组队列，其相比所述关联数据队列多了一个维度的数组用于保存指令是否已经写回的信息队列；

控制状态寄存器写FCSR监测线程，与所述浮点计算模块写FCSR监测线程一致，根据控制状态寄存器的指令的写使能条件对线程监控条件进行对应改变；

控制状态寄存器写CSR监测线程，分辨不同类型CSR寄存器地址，按照条件进行监测；

控制状态寄存器写特权CSR监测线程，用于监测特权CSR的写行为；

扩展寄存器模块的检查线程，用于扩展寄存器的写行为监测；

写内存模块的检查线程，用于内存的写行为监测。

3.根据权利要求2所述的基于RISC-V处理器验证的模拟器比对系统，其特征在于，所述仿真日志输出模块，具体用于：

对所述浮点计算模块写FCSR监测线程和所述控制状态寄存器写FCSR监测线程的历史关联数组队列进行处理和排序，具体包括：定义一个当前临时变量用于保存当前处理到的FCSR中的值；当两个历史队列都不为空时，若浮点计算模块写FCSR监测线程中的历史时间戳大于控制状态寄存器写FCSR监测线程中的历史时间戳，将浮点计算模块写FCSR监测线程中历史保留的写FCSR值与当前临时变量中的值进行或操作，把或运算的结果作为实际写回的值记录到浮点计算模块写FCSR监测线程中关联数组队列中，同时把当前临时变量的值改为所述或运算的结果；若控制状态寄存器写FCSR监测线程中的历史时间戳大于浮点计算模块写FCSR监测线程中的历史时间戳，把控制状态寄存器写FCSR监测线程中历史保留的写FCSR值作为实际写回的值记录到状态控制寄存器模块写FCSR监测线程中关联数组队列中；然后进入下次历史关联数组队列的时间戳比较；两个模块中历史队列如果有一个为空，就将不为空的那个模块队列剩下的元素按照同样的规则作为实际写回值写回到那个模块的关联数组队列中，从而完成对FCSR写行为的重新排序；

将不同队列中的关键属性和信息输出到RTL仿真日志中，包括：遍历PC监测线程中所保存的PC队列，把队列中每个元素作为一个KEY键值，把所述PC、对应的指令编码以及周期计数作为字符串输出到日志中；使用所述key键值去匹配不同线程中保存的关联数组队列中的元素；每当KEY在每个关联数组中找到了对应的元素，就将这个元素数组队列中队首的元素数组的每一个维度的值以固定的格式组成为字符串，然后输出到日志中，同时将所述元素数组从元素数组队列队首删除；且，按照先后顺序使用KEY键值去查找各个线程中保存的关联数组队列时，所述顺序与模拟器保持一致；

设定情况下，在日志输出时加入判断条件来满足验证比对要求；所述设定情况包括定点寄存器地址为0时不能写和控制状态寄存器不需要比对。

4.根据权利要求1所述的基于RISC-V处理器验证的模拟器比对系统，其特征在于，所述仿真日志输出模块对设定情况下的后处理工作包括：中断调试模式标签的插入、不同模块写同一类型寄存器时的行为顺序调整和设定情况下写寄存器行为的忽略。

5.根据权利要求2所述的基于RISC-V处理器验证的模拟器比对系统，其特征在于，所述仿真比对模块，具体用于：

分别加载RTL仿真日志和模拟器仿真日志，并分别对两个日志文件做如下处理：获取含有PC值的一行字符串，把其中的PC值提取作为一个key键值，将其加入到一个key值队列中，并将这一行字符串保存在一个字符串队列中；遍历日志文件，把遍历到的所有字符串信息保存到所述字符串队列中，直到遍历到下一个含有PC值的一行字符串；把所述字符串队列作为以PC值为key的关联数组，加入到这个PC值所关联的数组队列中；解析下一个Key值和其关联的字符串队列，以此类推；

比对的过程中，将其中一个日志创建的key值队列中的每个key作为比对单位，从头到尾遍历key值队列进行比对；其中，以一个key作为比对单位时，先比较key值关联的两个日志文件所创建的关联数组队列的长度是否一致，如果不一致，按照执行的指令不一致报错；一致时，对字符串关联数组队列中的每个子元素队列的长度进行比较，如果不一致，按照所写寄存器和存储器的行为不一致报错；一致时，判断每个子元素队列中的每个字符串元素的值是否相同，不相同时报错。

6.根据权利要求1所述的基于RISC-V处理器验证的模拟器比对系统，其特征在于，所述RTL仿真日志和所述模拟器输出日志遵守相同的格式，所述格式包含指令执行的PC值、指令操作码、写寄存器类型、写寄存器的编号或地址、写寄存器的值和写寄存器时的当前周期数。

7.根据权利要求6所述的基于RISC-V处理器验证的模拟器比对系统，其特征在于，所述比对系统基于每一条指令的PC值定位指令的位置和仿真波形中对应指令执行的时间点；以及，通过将指令操作码反汇编成对应的指令字符串确定哪条指令比对异常。

8.根据权利要求2所述的基于RISC-V处理器验证的模拟器比对系统，其特征在于，所述比对系统在检查到进入中断处理程序和调试只读程序时，在RTL仿真日志的对应位置插入中断调试开始和中断调试结束的标签；在比对的过程中，如果模拟器不支持中断调试功能，在比对时忽略中断调试开始和中断调试结束标签之间的全部指令PC的比对。

9.根据权利要求8所述的基于RISC-V处理器验证的模拟器比对系统，其特征在于，在所述PC监测线程还用来：

建立一个IRQ_START_MAP关联数据队列和一个IRQ_END_MAP关联数组队列；

当获取有效PC后，对中断或调试的跳转信号进行监测，如果当前没有中断跳转，则将一个空队列插入到跟当前PC相关联的IRQ_START_MAP关联数组队列中；如果当前有中断跳转，则将第一字符串标签插入到IRQ_START_MAP队列中；以及，

若当前中断处理程序没有结束，将一个空队列插入到跟当前PC相关联的IRQ_END_MAP关联数组队列中；如果当前中断处理程序结束，将第二字符串标签插入到IRQ_END_MAP队列中；

当进入仿真日志输出模块时，优先判断当前PC是否在IRQ_START_MAP有关联的元素，如果有需要先将第一字符串输出到日志文件中；再判断当前PC是否在IRQ_END_MAP有关联的元素，如果有需要将第二字符串输出到日志文件中；在进入仿真比对模块后，首先设置一个flag，如果日志文件行出现了第一字符串，就将flag置1，表明从当前时刻往后只要flag不清0，就不进行比对，直到日志文件行出现了第二字符串。

10.根据权利要求1所述的基于RISC-V处理器验证的模拟器比对系统，其特征在于，所述比对系统在仿真日志中加入仿真开始和仿真结束标签，在指令检查输出日志的过程中，加入指令执行周期数的信息，并同时加入到仿真日志中，用以算出仿真过程所需要的周期数和指令序列执行所用周期数。