解读《多线程向量处理器验证技术的研究》

Posted 2021-04-21 路科验证

rockeric.com

随着集成电路工艺水平以及计算机体系结构技术的不断发展，微处理器的性能在过去的几十年中呈指数级的增长，伴随而来的是微处理器设计规模以及复杂度也快速增加。随之而来就是验证的难度急剧增加。当前高性能微处理器验证面临的挑战主要为以下三个方面：1.验证周期长，效率低。2.验证覆盖率难以保证。3.定位并调试错误难度大。一般对于处理器的验证，通常采用分层次，多平台的验证。采用的验证方法一般是采用以模拟验证和形式化验证相结合，软、硬件协同合作的验证方法。本篇论文就是一个处理器验证的例子，从模块级到核级再到系统级，采用了形式验证，动态仿真以及硬件加速器相结合的验证方法，最后完成了对一个处理器的验证工作。

 

处理器的模块级验证

在处理器的结构确定之后，设计被划分到各个设计子模块，各个模块的设计验证同时启动。对于验证来说，模块级的验证可以采用多种验证形式，包括定向验证（Directed Verification）,随机验证（Random Verification）或者形式验证（Formal Verification）。形式验证一般主要用于局部逻辑区域的功能验证，其验证速度快，不需要编写测试激励就可以对电路进行静态分析。可以加快测试激励的编写，测试平台的搭建等前期准备过程。常用于前期功能验证的形式化验证工具一般有等价性检查（Formal equivalence check）和静态属性检查（Formal property check）。目前，针对多核处理器的形式化验证的研究主要集中在高效化形式验证引擎，模块级的形式验证，cache一致性检查以及NoC行为检查等。

带约束的随机化验证是模块验证采用的主要方法。UVM是目前模块级验证平台的主要结构。功能覆盖率与代码覆盖率的提升是推动验证过程的主要驱动力。例如对于处理器核DEC模块的验证。

如图是DEC模块的示意图。DEC是处理器核心的控制模块之一，主要实现指令的分派，指令的定序以及线程调度等功能。

对于该模块的验证，测试激励的产生主要是利用SV的随机函数以及约束产生的。将DEC模块的输入接口的激励分别分为bx_pkg, fp_pkg, sx_pkg, mx_pkg, ls_pkg,uop_pkg等六组，分别对应分支处理，浮点运算，简单数处理，复杂数处理，访存处理，微操作控制等六个功能。六组信号通过随机构成测试激励，输入给待测模块和参考模型。

基于覆盖率驱动的验证，随着对处理器核的不断验证，代码覆盖率和功能覆盖率逐渐趋于稳定，在验证过程中需要对未覆盖到的代码或者功能进行有针对性的分析，并根据分析结果增加或修改激励。

对于这种动态仿真验证，激励的形式大约可以分为两类。

第一类就是上述的带约束的随机激励。受约束的随机激励可以在很短时间内以较少的测试用例来覆盖到较多的测试场景，得到更高的覆盖率。受约束的随机激励在处理器的验证过程中特别适用于操作数的取值，操作码的取值，指令序列的组合的验证。

第二类是直接激励。一般在设计验证初期，常常采用手工编写的向量集合作为模拟激励。这种测试激励通常由设计者来完成，其最关注的是基本功能和重要的边界情况。另外在模块验证后期某些特殊的功能无法很好的被随机激励覆盖或者某些关键用例一般也编写具有针对性的测试用例。

 

处理器的核级验证

处理器核的验证主要是确认处理器核各个部件功能的正确。再对各个设计模块充分验证之后，将多个模块按照一定的连接和时序关系构成更高层次的功能部件，并对其进行核级的验证，主要验证各个子模块间通信、控制和协议实现。将各个功能部件按照体系结构和相互间定义的接口协议构成一个最终要实现的系统，并完成核级系统的验证。

由于处理器核的存在，核级的验证平台主要包括核级的DUT，加载测试程序的引导部分，memory模型，覆盖率以及比较器等。一般将测试文件编译成二进制代码，加载到memory模型中去，引导处理器核加载memory中的代码，执行测试程序，并与比较器进行比较。验证平台测试层的测试集由 C 程序、汇编程序以及初始化代码等构成。

对于核级测试的测试用例，也可以分为直接测试和随机测试两大类。

直接测试主要测试各个子模块在处理器核级的功能正确性，用于发现结构性定义错误。大规模的随机指令测试主要在项目后期设计代码初步稳定之后完成。直接测试的测试用例一般应该覆盖到处理器核的整体功能，相关指令的译码，浮点部分的运算，中断处理，指令集中每条指令的执行情况，访存部件的处理功能等。定向测试对于有针对性的功能部件进行验证较为有效，但在很多边界条件下，使用随机指令测试可能会发现更多指令组合的问题。

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

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

 

处理器的系统级验证

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

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

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

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

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

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

    

对于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的硬件仿真平台，实现系统级验证。通过代码覆盖率、功能点覆盖率收集，使用覆盖率来驱动了整个验证过程。

点击【阅读原文】下载论文