一种基于参考模型的GPDSP指令流控自动验证方法*

王慧丽，郭 阳

(国防科技大学计算机学院,湖南 长沙，410073)

1 引言

随着基于集成电路硬件实现的深度学习算法在气象预测、生物识别和人工智能等应用中的迅速发展，集成电路硬件设计规模逐渐扩大。作为处理器核心部件的指令流控单元，其设计复杂度日益增加，指令流控的验证难度随之增大。在一个控制复杂的应用场景中，指令流控错误可能会付出非常惨痛的代价。因此，对指令流控的高效、完备、精确的验证，是微处理器设计及验证中必须攻克的重要难题。

硬件设计的验证方法主要有2种[1]：基于模拟的定向功能验证和基于随机激励的形式化验证。基于模拟的定向验证一般采用人工编写的方式，针对指定功能进行测试激励，包括模块级验证和系统级验证2种。定向功能验证方法的主观依赖性较高，其验证的正确性、效率和完备性等与验证人员的经验素质密切相关，并且由于定向功能验证往往针对特定模块进行人工编制，导致激励可重用性不高[2,3]。基于随机激励的形式化验证能够对设计进行状态遍历，验证覆盖率高，但是在复杂的控制系统中，随着控制流程的增加，会出现状态爆炸问题。并且随机激励约束编写要求验证人员具有很高的设计水平，否则可能会出现随机激励的验证盲区，或者产生对验证功能点的重复覆盖，进而降低验证效率[4,5]。

基于参考模型的随机验证方法介于传统验证和形式化验证之间，该方法一般适用于数据密集型设计的模块级验证(如DMA、Cache和运算单元等)。对于控制复杂型的设计(如指令流控、中断系统等)，其与外部有复杂的协议，且内部功能复杂，因此很难在模块级生成随机激励并构造参考模型，而是将其嵌入到整个DSP核系统级环境中，进行基于参考模型(模拟器)的验证[6]。这种系统级的验证存在调试不便、无法大批量运行和EDA软件仿真速度慢等缺点。

无论采用哪种验证方法，验证的目标都是达到较高的覆盖率来保证验证的完备性和覆盖的全面性。覆盖率一般包括代码覆盖率、功能覆盖率和断言覆盖率[7]。在覆盖率驱动的验证中，参考功能覆盖率和代码覆盖率能够快速评估当前的设计和验证情况。如果出现2种覆盖率不一致的情况时，可能需要考虑设计是否合理，功能点提取是否准确，是否需要形式化验证工具辅助进行状态遍历等一系列问题[8]。

本文以自主高性能GPDSP处理器FT-xDSP的指令流控部件为研究对象，通过对其逻辑进行合理划分简化了其与外部的协议，然后经过一些侵入式验证设计方法处理之后，降低了在模块级进行随机验证的难度。最终针对难以进行定向模拟验证的功能点，提出了一种基于指令重排参考模型的指令流控自动验证方法。实验及实际验证的结果表明，该方法能够发现隐藏的验证边缘情况，并针对设计中的薄弱点进行定向的随机验证，从而大大提高指令流控的验证效率。

2 FT-xDSP的指令流控机制

2.1 指令流水线结构

FT-xDSP是国防科技大学自主研发的高性能浮点向量DSP，采用了基于VLIW的标量/向量协同架构，40/80位可变长度指令集，单时钟周期可并行发射1～11条指令[9]。FT-xDSP的指令流控部件主要包括一级程序Cache(L1P)、取指部件(PG，PW，IF三级流水线)、指令派发部件(DP)和流控指令处理部件(BR)。

图1给出了其指令流水线结构。其中，PG根据分支、中断和顺序自加地址生成指令包(512 bit对齐)请求地址；L1P向外部存储获取指令包并提供给取指部件和DP。DP对指令包进行拼接和译码，将指令派发到对应功能部件；BR处理流控指令，改变程序运行的轨迹，分支指令SBR执行程序的跳转，中断返回指令SIERT控制程序在中断程序执行完毕后返回主程序；其他10个功能部件负责运算或者访存操作。

Figure 1 Instruction pipeline structure图1 指令流水线结构

2.2 指令与执行包格式

FT-xDSP包按照512 bit对齐，指令在取指包中紧密排列。指令格式如图2所示，其中并行位P表示下一条指令是否可以与当前指令并行派发，L标记指令长度为40位或80位，Type表示该指令所对应的功能部件，Op为指令的其他操作码。

Figure 2 Instruction format图2 指令格式

单时钟周期内可并行发射的指令称为一个执行包(EP)。如图3所示，EP0～EP2分别为连续的3个时钟周期发射的执行包，每个执行包中可以包含多条紧密排列的80位指令或40位指令。

Figure 3 Execution package in the fetched package图3 指令包中的执行包

2.3 指令程序流

FT-xDSP中的程序执行顺序有3种：顺序、分支跳转和中断响应，图4为其所对应的程序流示意图，其中：

(1)图4a为顺序程序流，程序运行轨迹为：EP1→EP2→EP3→…。

(2)图4b为分支跳转程序流：EP1中包含一条分支指令，经过6个分支延迟槽后，程序跳转到分支目标地址(图4b中示例为EP10)。程序运行轨迹为：EP1→EP2→EP3→…→EP7→EP10→EP11→…。

(3)图4c为中断响应程序流：程序执行过程中发生了中断事务，当前程序被中断执行并跳转至中断程序，直至中断事务处理完毕后，再返回至原来程序被打断的地方继续执行。程序运行轨迹为：EP1→…→EP5→Int_EP1→…→Int_EPn→EP6→…。

Figure 4 Three kinds of program execution sequence图4 3种程序流的执行顺序

3 指令流控部件验证策略

3.1 验证功能点分析

指令流控部件验证的核心工作是验证用户程序中的所有指令是否按照预定的程序流被正确地派发到相应的功能部件中，而不需要验证一条非流控部件指令(如运算指令、访存指令等)是否可以被正确执行。验证过程中难以用传统模拟方式进行验证的功能点主要有如下几个：

(1)协议验证：指令流水线中几个控制功能部件之间存在着繁杂的通信协议，而在遇到分支与中断时，验证会变得很复杂，通过手工编写测试激励难以遍历所有情况。

(3)程序流验证：分支跳转程序流中，涉及到分支延迟槽的处理、分支延迟槽或者分支目标执行包跨边界、分支延迟槽对中断的抑制等情况；中断响应程序流中，当前中断地址保存、当前流水线排空(Flush)和中断返回地址处理等情况都是验证过程中的难点，也是在DSP芯片单核设计中最容易出现设计缺陷的地方。尤其当分支和中断发生频率较高，且存在大量跨边界执行包时，验证工作更加艰难。

3.2 验证策略分析

传统模拟验证方法，通过手工汇编用户程序，在用户程序中加入分支、中断等相关配置，构造可以触发相应功能点的测试激励程序(指令包)。激励输入到DUT中，最终输出为测试激励程序所预定的程序轨迹和对应执行包。

表 1所示为图4b分支跳转程序流的人工汇编程序示例。其中EP2中仅有1条指令，EP11则包含11条指令。程序运行时，指令被派发至功能部件的时间顺序如表 2所示。此激励可验证包括分支延迟槽计数、取指地址缓冲、各部件协议、指令包译码、跨边界执行包(如EP6,EP11)、PC值维护和指令并行度等硬件逻辑，而不需要关注其中每一条指令执行结果是否正确。如果在分支延迟槽(EP2～EP7)中再插入分支指令构造多层循环嵌套，或者期间发生中断响应，汇编程序本身变得复杂的同时，表 2中对程序正确派发顺序的分析也非常耗时耗力，容易因繁琐的细节而导致设计错误未被及时发现。

Table 1 Example of a branch jump program

Table 2 Execution sequence of branch jump program

综上所述，指令流控部件的自动化验证策略需要解决以下问题：

(1)可以自动生成执行包并行度可配置的随机指令测试激励，并且能够在执行包中加入合法可控的分支指令，在程序流中插入中断事件，构造合法的分支跳转程序流和中断响应程序流，缩短编写验证激励的时间。

(2)需要一个高层次参考模型，能够快速准确地得到随机测试激励的正确结果，减少验证人员结果分析的时间。

(3)具有结果自动对比功能和收集覆盖率的功能，便于错误定位和覆盖率统计。

基于以上分析，本文提出基于指令重排参考模型的自动验证方法，用于提高指令流控的验证效率和验证完备性。

3.3 自动验证方法概述

如图5所示：基于参考模型的自动验证方法以抽象的参考模型为基础，将批量自动生成的随机测试激励同时输入参考模型和指令流控部件DUT，监测二者的输出，并进行结果自动对比，然后根据覆盖率情况调整产生随机激励的约束，实现功能点和代码的快速全覆盖。

Figure 5 Automatic verification based on reference model图5 基于参考模型的自动验证方法

基于参考模型的自动化验证方法包含3个重要部分：

(1)激励生成：生成符合条件的随机测试指令包，并在这些测试激励中插入合法的全局控制信号和分支/中断操作。

(2)参考模型：对指令包进行译码，并根据分支指令/中断响应进行分支/中断程序流的处理，产生标准结果队列。

(3)结果分析：以SVA(SystemVerilog Assertion)断言的方式，实时监控DUT的输出是否与参考模型的标准结果保持一致，并对覆盖率进行统计和分析。

4 基于指令重排参考模型的自动化验证方法

4.1 激励自动生成

激励的自动生成包括3部分：一是指令码的生成；二是全局控制信号的生成，如全局停顿信号、中断清空流水线信号IH_Flush等；三是取指地址生成，包括分支跳转目标地址、中断程序入口地址和中断返回地址的生成。

4.1.1 指令码生成

随机指令码生成主要是针对执行包并行度的验证，以及不同指令流在遇到不同并行度执行包时，触发其他复杂功能点的验证。指令码生成采用受约束的随机方法[10]，以保证执行包合法有效，其生成过程如图6所示，分别为11个功能部件(U0～U10)建立有效指令集合，即每个功能部件中包含所有合法的Type和L组合。在随机生成指令执行包时，根据限定的并行度P，随机选中P个功能部件，并在这P个功能部件中随机选择一组有效的Type/L组合，与完全随机值Op进行拼接，最后紧密排列构成一个执行包。重复以上过程，将生成的执行包在存储模型中依次排列，作为参考模型和DUT的测试指令包。图6中示例了并行度为3的执行包EP0和并行度为4的执行包EP1的产生过程。

Figure 6 Random generation of instructions with constraint图6 受约束的指令码随机生成

随机生成的指令码直接输入参考模型中进行指令解析，同时搭建一个存储体模型ASRAM实现与DUT中L1P的取指包通信，将激励输入至DUT中，如图5所示。

4.1.2 全局控制信号生成

流水线停顿信号G_Stall可在没有取指缺失造成的全局暂停的情况下随机产生；中断事件引起的清空流水线信号IH_Flush可在程序没有处于分支延迟槽中的情况下随机产生。

4.1.3 取指地址产生

在基于模拟的验证中，分支地址、中断地址由编译器辅助生成[11]，而中断返回地址由硬件记录。在指令重排参考模型中，这些地址需要采用非完全随机的方式，按照4.2节中不同程序流的处理方法而采用不同的产生策略。

4.1.4 可参数配置的定向激励生成

为了针对特定功能进行验证，可以通过对随机数进行参数配置实现激励的定向随机产生，包括以下特征配置：

(1) 并行度可配置：可以配置激励中执行包的并行度P为固定值，或者为一个范围内的随机值；

(2) 指令长度可配置：一个执行包中80位/40位指令出现的概率；

(3) 异常可配置：一个执行包中是否出现指令派发异常或者流控部件指令错误异常；

(4) 分支指令和中断事件发生的概率可配置。

4.2 指令重排参考模型

指令重排参考模型的核心工作是对顺序程序流、分支程序流和中断程序流的处理，如图7所示，该模型对输入的测试程序指令包(如表 1中示例)和中断控制信号进行执行包和程序流的分析，将解析出的执行包按程序实际运行顺序在时间上进行重新排列(如表 2中示例)，生成标准结果队列。其中，分支/中断地址的产生需要在程序流处理过程中以受约束的随机方法产生，以保证其合法有效性。

Figure 7 Modeling for instruction flow control图7 指令流控建模

4.2.1 顺序程序流处理

当激励中不包含分支类指令且无中断事件发生时，参考模型根据指令的P,L,Type域，对指令包进行由低位到高位的顺序译码，将译码后得到的执行包首地址PC_x(x=1,2,…)、执行包内包含的功能部件指令Uy(y=0,2,…,10)和该执行包的异常信息保存至一个顺序指令队列，如图8所示。图8中x为用户程序指令包在存储中的实际位置编号；y为功能部件标号(0～10)；Mem_ptr为该指令队列的读指针，表示当前执行包在存储中的绝对位置。在顺序程序中，Mem_ptr与标准结果队列读指针DP_ptr相同。图8的顺序程序流的结果队列中，PC_n+2的执行包包含2条属于同一功能部件的指令U1，引发指令派发过程中的功能部件冲突异常，因此异常信息一列标注为1。

Figure 8 Instruction queues of sequential program图8 顺序程序流的指令队列

4.2.2 分支跳转程序流处理

在进行分支跳转程序流处理时，先按顺序程序流处理方式将指令包解析为顺序排列的执行包，如图9a所示。在此基础上，增加一个分支控制处理队列，如图9b所示，分支控制队列与顺序队列共用一个指针Mem_ptr。分支跳转程序流处理主要包括以下几个方面：

Figure 9 Processing of branch test program图9 分支测试程序处理

(1)分支指令识别及分支地址产生。

在DUT中，分支指令的分支目标地址由指令Op域计算得出，或由Op域指定的寄存器中的值决定。在参考模型中，由于分支指令部分指令码是随机生成的，因此为了保证分支目标地址的合法性，同时降低验证的难度，分支目标地址在所有有效的执行包地址PC_x中随机产生，并在DUT顶层对分支目标地址进行旁路，使得DUT的分支目标地址与参考模型保持一致。如图9a所示的测试程序，当某个Mem_ptr所指向的执行包中出现分支指令(如属于U4功能部件的BR1和BR2)时，则在图9b的分支控制队列中对应Mem_ptr指向的行中标记BR_Valid为1，同时，在顺序队列中随机选择一行作为分支目标执行包，将其Mem_ptr保存至该行BR_ptr中。

(2)执行包重排序。

根据图9中的信息，将分支指令流按照指令派发的顺序写入一个新的队列中。如图10所示。图10a中分支指令BR1之后，经过6个延迟槽，程序跳转至BR1的随机分支目标地址PC_n继续执行；分支指令BR2之后，经过6个延迟槽，程序跳转至BR2的随机分支目标地址PC_1继续执行。分支跳转程序流重排序后，分支控制处理队列也随之重新排序，新的队列指针为DP_ptr。重排后的指令队列即为分支跳转程序流的标准指令派发结果队列。

Figure 10 Reordering branch jump program图10 分支跳转程序流重排序

(3)循环次数计数。

图10中，分支指令BR2会使程序在PC_1～PC_8这8个执行包之间不断循环，导致其他随机生成的执行包无法被验证。因此，图10b中加入分支指令执行次数Cnt的计数。Cnt对包含分支指令的执行包的派发次数进行累加，当Cnt超过某一阈值时(例如10)，则将参考模型中的分支指令标志位BR_Valid置0，并通过旁路将BR_Valid输入DUT作为分支的跳转条件，使DUT中的分支指令不再执行，从而规避程序进入死循环的情况，确保随机激励的高效性。

Figure 11 Processing of interruption test program图11 中断测试程序处理

4.2.3 中断响应程序流处理

在实际应用中，不同中断事件具有不同的中断响应程序。在本文的参考模型中，因为不需要关心中断程序的具体功能，因此所有的中断均采用相同的中断响应程序，并将中断响应程序放置于生成的随机激励最末端的特定地址。

中断响应程序流的测试程序如图11a所示，在随机生成的测试激励最末端，增加一段中断服务程序(Mem_ptr=m)，该程序中包含3条指令(可扩展为多条)，其中IRET为中断返回指令，NOP6为空转指令用来填充6个延迟槽。中断响应程序流处理时，在分支跳转程序流的基础上增加了一个中断标志队列，如图11c所示，该队列中随机标记分支延迟槽以外的执行包所在行为1，表示执行当前执行包时，发生了中断响应IH_Flush，并触发清空流水线的操作。同时将此时的程序地址指针作为中断返回地址指针Ret_ptr保存至图11b的BR_ptr中。

图12为中断响应程序流重排序处理。当执行到IH_Flush为1的执行包时(PC_n+1)，当前程序停止执行，清空在指令流水线中的所有指令，并将该执行包地址指针(Mem_ptr=n+1)作为中断返回地址指针Ret_ptr写入IRET指令所在行的BR_ptr中。然后，程序跳转至激励尾部的中断响应服务子程序处(Mem_ptr=m)开始执行。在Mem_ptr=m+1处中断响应程序处理完毕，执行中断返回指令IRET，6个延迟槽后，程序流返回到保存的中断返回地址Ret_ptr(Mem_ptr=n+1)处继续执行主程序。IRET指令的Cnt始终为0，以确保每次中断响应后，均可以正确地返回到主程序。图12a即为中断响应程序流的正确派发结果。

4.3 结果自动对比与覆盖率统计

4.2节中测试程序经过分析处理后，生成一个按照指令派发顺序排序的标准结果队列，如图8、图10a和图12a所示。为方便描述，将结果队列中包含的3列信息分别命名如下：EP首地址为ResultPC_Mem，EP中指令为ResultU_Mem，异常信息为ResultExp_Mem。以图10a中分支跳转程序流的验证为例，其波形如图13所示，其中Ux_Inst和DP_PC分别为每个时钟周期DUT输出的执行包及其首地址，Ux_Inst中阴影部分表示当前时钟周期派发了一条该部件的指令，Exprition为异常事件。在没有全局停顿信号G_Stall时，结果队列读指针DP_ptr由0开始递增读取标准结果，并通过SVA断言监控DUT的运行结果是否与结果队列保持一致[12]，同时对功能点覆盖率和覆盖次数进行统计。如下所示为部分基于SVA断言的结果对比和功能覆盖点。若结果对比失败则打印错误发生的时间和错误类型，保存相应激励进行调试和回归验证；功能覆盖点则可以统计该功能点是否被覆盖，以及被覆盖的次数，从而评估该组激励对功能点的验证分布情况。

Figure 13 Debug waveform of branch test program图13 分支测试程序的调试波形

基于SVA的结果自动对比示例：

assert_DP_PC:assert property (@(posedge clk)

disable iff (～rst_n) if (!G_Stall)ResultPC_Mem[DP_ptr]==DP_PC);

assert_U1_Inst:assert property (@(posedge clk)

disable iff (～rst_n) if (!G_Stall)ResultU_Mem[DP_ptr]==U1_Inst);

基于SVA的功能覆盖点统计示例：

cover_TH_Flush_U1:cover property (@(posedge clk)

disable iff (～rst_n) if (!G_Stall)U1_Valid&&TH_Flush);

cover_TH_Flush_with_GStall:assert property (@(posedge clk)

disable iff (～rst_n)TH_Flush&&G_Stall);

5 实验与分析

本文采用Verilog/SystemVerilog语言对基于参考模型的指令流控自动验证平台进行设计实现，进行了大量的模拟验证并对覆盖率信息进行统计收集。实验从激励有效性、覆盖率、仿真效率和可移植性等方面进行了分析。

5.1 激励有效性分析

在对测试激励的自动生成进行了参数配置后，通过检测激励运行过程中断言被触发的情况，判断激励生成是否符合参数配置。如表 3中所示，配置执行包中是否生成VLS0/VLS1指令，分别批量生成测试激励后，对比验证过程中断言触发次数，可以看到参数配置是有效的。如果将功能点全部由断言进行描述，则可以根据断言被触发的次数，清晰地得到某类激励验证的功能点的分布情况，进而调整测试激励参数配置，避免对同一个功能点密集覆盖而其他功能点无覆盖或覆盖较少的情况。

5.2 覆盖率评估

代码覆盖率中，块覆盖率(Block Coverage)一般要求达到100%，表达式覆盖率(Expression Coverage)一般要求达到95%以上。如表4所示，模拟覆盖率为基于模拟的人工编写代码验证的覆盖率数据，合并覆盖率为在增加了基于参考模型的

Table 3 Evaluation of effectiveness of parameter configuration

随机激励验证后， DUT的覆盖率数据(其中未覆盖的项为ET测试相关)。2组覆盖率数据表明，基于指令重排参考模型的随机激励验证方法是有效且全面的。

功能覆盖点在本文中由2部分组成：验证前期根据功能验证文档，基于模拟验证所进行的功能点验证统计，以及验证后期基于参考模型随机激励的验证中，使用SystemVerilog进行Coverage point描述的覆盖点统计，二者最终实现所有功能点的全覆盖。本文验证方法的代码覆盖率如表4所示。

Table 4 Evaluation of code coverage表4 代码覆盖率评估

5.3 仿真效率分析

在FT_xDSP中，传统模拟验证与参考模型随机验证对指令流控部件验证进度的贡献如图14所示。在验证中后期，传统模拟验证效率开始降低。增加参考模型随机验证后，受益于随机激励可以通过脚本快速迭代生成，以及对各种复杂随机激励的结果可以自动对比分析的优势，更多处于模拟验证盲区的错误得以快速暴露，加快了验证收敛速度。

Figure 14 Contribution of simulation verification and random verification to instruction flow control verification图14 模拟验证与随机验证对指令流控验证的贡献

为了评估模拟验证和参考模型随机验证在同等条件下的验证效率，人为在已经成熟验证的指令流控中插入10个不同类型的错误。2种验证方法在仿真时间上的对比如图15所示。虽然2种方法在验证某些类型的功能点时分别出现了效率降低的情况，但是，参考模型随机验证在总体仿真时间上较传统模拟验证更有优势，足以弥补其在参考模型搭建和受约束的随机激励生成等方面所花费的时间。

Figure 15 Comparison of simulation time between simulation verification and random verification图15 模拟验证与随机验证仿真时间对比

5.4 可移植性分析

由图14可知，减少平台开发时间(t)可以更早发现验证盲区，缩短验证周期。基于指令重排的参考模型，抽象层次高，只需要对取指地址产生逻辑进行修改，便可集成在系统级环境中。激励自动产生方法和参考模型的指令队列重排方法，适用于多数指令集系统和指令流水线结构，可以通过微调移植到不同的硬件设计中，从而大大节省验证平台开发时间。

6 结束语

本文重点介绍了自主高性能GPDSP处理器FT-xDSP的指令流控系统的验证方法，在基于人工编写测试激励的模拟验证已经完成，但是仍有一些复杂功能以及验证薄弱点难以通过人工编写测试激励进行代码覆盖的情况下，提出了一种基于参考模型的随机验证方法。实验及实际验证的结果表明，这种随机验证方法能够快速生成大量可配置的定向随机激励，大幅度提升验证效率，并且在不同芯片设计中具有可移植性。但是，本文中的参考模型在处理分支跳转和中断事件响应时，对原设计DUT的地址产生有侵入式设计，在整个芯片的设计验证流程中要注意防范因此造成的代码版本管理问题。另外，指令流控部件的功能覆盖率依靠简单SystemVerilog描述实现，且未对所有功能点进行描述，统计方法过于简陋，在下一步的工作中将对本文提出的方法做出进一步的实验和完善，在验证平台中加入covergroup进行功能点的自动收集。