除此之外，还需要设计一部分的底层测试代码，例如

处理器核级的验证规模已经相当庞大，处理器内部功能模块众多，各个模块间交互协议复杂，很难在处理器核级将整个核的功能进行完整验证。所以引入随机测试激励非常有必要。

处理器的系统级验证

处理器的系统级验证主要验证两方面的内容：一方面测试各子系统协同工作的功能正确性；另一方面各自模块连接的输入来自真实设计，能弥补或增强子系统测试中定向或随机测试中并未覆盖的场景。

处理器的系统级验证环境一般采用硬件仿真加速器，该环境下的设计代码和测试激励都综合到硬件仿真加速器内，系统外部 I/O 设备通过转接卡与硬件仿真加速器连接。

测试内容一般包括处理器核的功能验证、存储系统的验证、外围 I/O 的验证、互连验证、调试逻辑验证和测试程序集验证等，这些验证内容可以并行进行或交叉进行。

系统级验证的流程设计到计算机系统的各个方面，包括软件和硬件的测试。都需要在系统级完成验证。

如图是一个典型的基于ICE模式的硬件仿真环境。

DUT即为处理器，外挂有4片FLASH，以及4片DIMM。挂载的Flash模型数量与DUT的Flash控制器，Flash模型大小，对Flash空间大小需求等因素有关。与Flash模型类似，挂接的DIMM模型数量取决于DUT的DDR控制器的设计。挂接DIMM模型主要是为了验证存储的访存通路，模拟芯片的真实应用场景，以及加载测试程序。

基于硬件仿真加速器，测试程序的加载一般遵循以下流程。首先，完成操作系统程序数据格式、地址的转换；将转换后的操作系统加载到Flash空间；引导操作系统；操作系统引导成功之后，利用基于asic硬件仿真加速器的状态保存功能，通过SaveState保存一个初始态；按操作系统分配的地址空间以及DIMM数据格式，对标准的测试程序包做格式转换，生成DIMM模型数据；通过Loadmem指令将DIMM模型数据加载到DIMM模型中；在操作系统中通过mount挂载的方式找到内存中用于存放测试程序的存储空间，运行测试程序；当DIMM模型中所加载的程序均通过测试后，利用硬件仿真加速器的状态恢复功能，通过RestoreState恢复到操作系统引导成功后的初始状态；重新加载测试程序，开始新的测试；如此反复。

对于UART, SATA,PCIE,USB,ETHERNET等微处理器芯片常用IO接口，硬件仿真加速系统也可以对这些控制器进行全系统级的验证。一般对于这些外挂组件有两种不同的验证方式。比如对于UART的验证来说，第一种就是在UART控制器外挂接一个UART模型，信息的输出以及外部命令的输入可以在仿真器的内部完成。另外一种就是通过硬件仿真验证平台自带的接口，挂接真实的设备进行检验。将UART控制器的并行数据发送到UART芯片，由UART芯片完成数据的串并转换之后连接到一台真实的电脑端口上，模拟真实的验证场景。对于其他的IO组件，如果其验证模型非常复杂的话，一般采用挂接真实的物理设备来进行验证，只不过对于不同的IO设备，需要选用相对应的速度匹配桥。

软件仿真器与硬件仿真器的协同验证

对于一些无法被综合的验证代码，例如SVA等无法很好地被硬件仿真加速器所支持，可以采用一种软件仿真器与硬件仿真器并行运行的验证环境，如图所示。

与基于 ICE的仿真环境相比，该环境最大的区别在于Ncverilog软件仿真器与基于ASIC硬件仿真器并行工作。根据DUT及验证环境是否完全可综合，该环境可有两种工作模式。当DUT或验证环境有部分不可综合代码时，编译时将可综合部分与非可综合部分分离，分别置于基于 ASIC 硬件仿真器与 NcVerilog软件仿真器中，可综合部分设计（或环境）可在软/硬仿真器间来回切换，但不可综合部分设计（或环境）仅能运行于软件仿真器上。软/硬仿真器间在信号层进行交互，这将在一定程度上制约整体仿真速度，具体影响大小与软/硬仿真器间信号交互频率、NcVerilog 仿真频率等因素有关，其基本的仿真环境如上图所示。当DUT 及验证环境均可综合时，为避免软/硬交互影响仿真频率，通常将整个设计均综合到基于ASIC硬件仿真器上，在运行过程中在根据调试需求将所有设计在软/硬仿真器间进行切换。仿真模式的切换流程如下图所示。通过 xc run、xc off、 xc free 可实现软/硬仿真器之间的切换。

总结

文章采用多层次、多平台、广覆盖的验证方法，并应用到了处理器的模块验证、处理器核级验证、系统级仿真验证。采用覆盖率驱动的验证方法针对处理器的各模块进行验证。对处理器核使用测试激励进行批量处理、大规模回归测试、定向测试和随机测试，建立基于硬件仿真的验证环境、基于 ASIC的硬件仿真平台，实现系统级验证。通过代码覆盖率、功能点覆盖率收集，使用覆盖率来驱动了整个验证过程。