浅谈可移植激励规范复用策略介绍

　　剖析可移植激励
　　可移植激励（下文简称PSS）语言在设计初期就考虑到了测试意图和自动化创建测试的要求。下图一就很好的展示了PSS是如何通过对于测试意图和测试实例的清晰区分，来达到对于测试意图的平台复用的。在PSS描述文件中，测试意图主要抽象定义了一个测试需要执行什么行为，是通过声明的形式来实现的。就如同在SystemVerilog语言中声明式的约束一样，我们可以通过这种方式得到比较好的复用性。
　　
　　图一 – PSS描述文件结构详解
　　通过这种声明式的语言特性，PSS很好地满足了复用和自动化的需求。通过这种特性，定义了合法空间中可以发生的行为，我们能够直接编写程序定义其行为内容而不是如何执行这种行为。如果有读者使用过SystemVerilog的约束特性，就能够明白约束定义的是合法激励数据范围。PSS语言正是将这种特性从数据定义扩展到测试场景的使用上，提供了一种新的元素-动作（action）。
　　然而支持这种声明式的语言特性并不够，因为测试本质上是需要和设计单元进行底层的互动，如修改寄存器或者中断等等来达到验证的目的。所以测试代码不仅仅是要定义抽象的测试场景，也需要能够定义底部的设计细节。另外绝大部分的验证环境已经拥有大量的测试代码供工程师使用，所以大多数情况下，工程师们会使用他们熟悉的编程语言如SystemVerilog、C++或C来实现所需要的可移植激励测试。
　　当然，我们使用PSS的最终目的是为了生成更多的测试用例，下图二就向我们展示了一个典型的PSS使用流程。在这种情况下，PSS文件一般会在测试生成过程中被执行。比如说，我们可以使用PSS来提供约束生成仲裁功能。在SoC环境下，我们会系统的处理器执行测试，此时我们可以提前使用PSS生成一些简单的测试用例来让处理器更高效快速的运行。
　　在这两种使用环境下，PSS都会将抽象的测试场景定义和测试生成两部分完全分离出来。
　　
　　图二 – PSS流程详解

　　详解可移植的含义
　　在详细讨论可移植激励应用设计策略之前，有必要花时间了解“可移植”本身的含义。接下来我们将从三个方面讨论如何更好地实施相应设计策略。
　　在讨论可移植测试特性时，我们经常会涉及到垂直复用这一术语。这个概念通常是指从项目早期 – 一般是指在IP层级 – 就开发出相应测试意图，以便在之后的验证流程中重复使用，比如子系统和系统层级。对于测试意图在各个层级上的垂直复用，能够提供一个全面健壮的测试库，有效帮助我们更快的搭建测试环境，同时进一步减少在开发过程中带来的程序错误。当然尽管垂直测试的好处多多，但是开发这种测试需要各个团队协作共同努力，比如我们需要IP层级的团队同时支持系统级和子系统级别的测试开发，另外也需要对已存在的IP开发相应的可移植激励描述文件。
　　水平复用则可以让测试意图文件在不同项目中工作，当然设计本身会有一些参数上的变化。但是可移植激励标准本身声明式的语言特性，能够有效降低对于参数调整带来的工作量。我们只需要调整测试规则即可，而不需要对测试意图本身进行更新。
　　
　　图三 – 垂直复用实例
　　如图三的实例，不同的SoC设计中可能包含不同数目的DMA引擎。如果使用直接测试的方式，我们需要检查所有测试文件，以确保他们检查SoC时使用正确的DMA引擎数目。但是使用可移植激励规范时，我们只需要调整DMA参数，即可以重新生成正确的测试文件。
　　最后一项可能比较难以理解 – 测试技术的可移植性。例如SystemVerilog的受约束随机特性，虽然可以有效帮助我们提升验证效率和速度，但是这种特性只能使用在模拟测试环境当中，无法使用在以C++为主的高级综合环境（HLS）中，也并不能使用在嵌入式软件测试中，因为一般来说，嵌入式系统的硬件资源有限，没有办法运行一个完整的SystemVerilog模拟器。
　　但是可移植激励规范的出现，让这些测试技术，比如自动化的受约束随机测试，能够在不同的测试环境中得以应用。这一益处本身也许就足够可以说服团队采用可移植激励规范。
　　在一个项目初期，团队就需要从以上三方面来考虑如何设计PSS策略，比如哪方面的复用更为重要，需要团队投入更多的资源进行开发。从而让整个项目能够最大化利用可移植激励带来的好处。

　　实例详解
　　我们接下来将用一个非常简单的实例来探讨PSS的实际应用，我们将继续使用图三展示的SoC设计框架，其中包含一个四核RISC-V处理器、一个外围设备子系统以及一些其他控制器组件。
　　接下来我们也会从组件层级讨论DMA IP。如下图四，我们可以看到一个组件级别的验证环境框架图。另外如图五所示，我们也会探讨一下如何从子系统级别嵌入一个DMA引擎、一个UART控制器和一个中断控制器。
　　
　　图四 – DMA引擎模块级环境
　　
　　图五 – 外围子系统验证环境

现有测试用例的复用
当我们完成文档的编写，接下来就是对代码库进行分析，来确定哪一些可以进行复用。我们可以利用这段时间来评估一下有多少现有代码可以继续用于当前项目。另外如果时机允许也可以借此来评估对整个组织内的相关代码，通过整合资源可以更好的提升开发效率。
约束
PSS描述文件绝大部分基于约束语句，这是由其声明特性所决定的。所以现有的一些约束文件也可以很轻易的转换成PSS格式进一步节省开发时间。

SystemVerilog的约束文件由于其声明特性，通常可以作为PSS描述文件二次再开发的来源。另外其本身语法特性与PSS非常相似，我们甚至可以直接拷贝复制进PSS文件直接进行使用。这种情况的使用案例是一些IP或者子系统的配置对象代码，可以这样复用在PSS文件当中。

通常约束文件可读性比较低，比如SoC的内存映射文件。但是通过一点点改动，我们就能将其改写成PSS约束，来专门定义不同内存空间的读取权限。
测试案例实现细节
团队现存的测试环境通常是一个非常好的实现基础，当然这其中需要花时间将其按照PSS的语法进行改动。

UVM环境中，我们会使用utility sequence来对IP模块进行简单的操作，比如初始化设置，命令其进行数据计算等等。这些序列在定义时通常有一些随机约束和变量。其他情况下，我们会通过输入参数来控制其工作模式。无论如何，我们都可以通过一些方法将其转换成PSS描述文件。
task init_single_transfer(  int unsigned        channel,  int unsigned        src,  int unsigned        inc_src,  int unsigned        dst,  int unsigned        inc_dst,  int unsigned        sz);  wb_dma_ch ch = m_regs.ch[channel];  uvm_status_e status;  uvm_reg_data_t value;    // Disable the channel  ch.CSR.read(status, value);  value[0] = 0;  ch.CSR.write(status, value);   // These registers are volatile. Read-back the content  // so the register model knows to re-write them  ch.A0.read(status, value);  ch.A1.read(status, value);图六 – SystemVerilog测试复用实例

图六截取了一段SystemVerilog代码，其中我们定义了一个virtual sequence的task，来设计DMA引擎在一条特定的数据通路上传输数据。这段代码就可以通过简单改写将其使用在测试DMA引擎的PSS模型中。需要注意的是，因为我们本身的代码使用了UVM，所以底层是使用了UVM寄存器模型来读取DMA引擎的相关寄存器。

void wb_dma_drv_init_single_xfer(  wb_dma_drv_t                *drv,  uint32_t                ch,  uint32_t                src,  uint32_t                inc_src,  uint32_t                dst,  uint32_t                inc_dst,  uint32_t                sz  ) {  uint32_t sz_v, csr;   csr = WB_DMA_READ_CH_CSR(drv, ch);   csr |= (1 << 18); // interrupt on done  csr |= (1 << 17); // interrupt on error  if (inc_src) {    csr |= (1 << 4); // increment source  } else {    csr &= ~(1 << 4);  }  if (inc_dst) {    csr |= (1 << 3); // increment destination  } else {    csr &= ~(1 << 3); // increment destination  }  csr |= (1 << 2); // use interface 0 for source  csr |= (1 << 1); // use interface 1 for destination   csr |= (1 << 0); // enable channel   // Setup source and destination addresses  WB_DMA_WRITE_CH_A0(drv, ch, src);  WB_DMA_WRITE_CH_A1(drv, ch, dst);   sz_v = WB_DMA_READ_CH_SZ(drv, ch);  sz_v &= ~(0xFFF); // Clear tot_sz  sz_v |= (sz & 0xFFF);  WB_DMA_WRITE_CH_SZ(drv, ch, sz_v);   // Start the transfer  WB_DMA_WRITE_CH_CSR(drv, ch, csr);   drv->status[ch] = 1;}图七 – 相关测试的C代码复用

上图是一个相似功能的C代码实现。我们同样也可以将其转换用在PSS测试中。

当然需要注意的是虽然两种代码实现的测试目的相似，但我们会讨论哪一种更适合用在PSS文件中。

　　创建可复用的PSS库
　　当我们开始考虑在公司内部创建PSS代码库时，通用的数据结构是需要优先考虑的一点。因为PSS还是一个比较新的标准，所以业界现在还没有一个标准化的通用数据库。但是我们非常建议在项目开始初期就为常用的数据结构创建一个通用库。这样做的原因是PSS描述文件本身会经常使用一些非常类似的数据结构，例如一个memory buffer需要定义其地址和内存大小。
　　struct data_mem_t {
　　rand bit［31:0］ addr;
　　rand bit［31:0］ sz;
　　}
　　图八 – 可复用的数据缓存结构
　　我们并不期望三个负责不同IP的工程师能够定义出相同的memory buffer structure。所以提前定义出共用的数据结构库，并确保团队及时的使用和维护，能够让PSS模型在子系统和SoC层面的复用变得不那么复杂。
　　另外我们也推荐创建一个IP层面的PSS代码规范。比如，所有IP层面的PSS action，都需要从一个通用的abstract action type继承出来。例如图九所示。
　　abstract action dma_dev_a ： pvm_dev_a {
　　// All transfers involve a channel
　　rand bit［7:0］ in ［0..7］ channel;
　　// Size of each transfer
　　rand bit［4］ in ［1，2，4］ trn_sz;
　　}
　　/**
　　* Transfer memory-to-memory
　　*/
　　action mem2mem_a ： dma_dev_a {
　　input data_ref_mem_b dat_i;
　　output data_ref_mem_b dat_o;
　　}
　　/**
　　* Transfers data to a memory address
　　*/
　　action dev2mem_a ： dma_dev_a {
　　output data_ref_mem_b dat_o;
　　input data_ref_s info_i;
　　rand bit［31:0］ src_addr
　　图九 – IP specific common base action
　　Type extension是PSS的一大特性，只有将所有PSS action全部从base action继承出来，才能在整个IP验证流程中更好的使用该特性。
　　创建可复用的数据产生和检查流程
　　测试结果的检查方式对于IP验证和SoC验证流程来说，有着很大的不同。IP层级的验证我们大多会使用基于scoreboard的检查，这样我们能够看到IP中的每一个数据操作是如何被执行的，也可以检查到最终的运行结果。但是在SoC层级，由于设计本身的局限性，我们一般只会检查最终的数据结果。
　　因此，如果公司内部比较看重垂直复用性，那么定义一个在IP层级和SoC层级可以同时使用的数据核查策略就显得非常重要。通常来说，我们在PSS描述文件当中会更多侧重对in-memory data最终结果的检查。
　　当然，我们也可以在implementation check基础上增加更多的functional check。例如在IP层级中，DMA引擎操作就可以通过纯粹功能性上的验证来进行测试，即接收端的数据和发送端的数据是否相符。IP层级上的scoreboard仍旧可用来检查DMA的传输操作，与此同时子系统和SoC层级上也能够复用这种验证策略，比如可以使用在对SoC的性能测试中。
　　测试实现的复用
　　针对相同的测试目的我们会有多种实现方式，对于验证工程师来说我们要学会利用UVM本身的各种特性，例如寄存器模型等。与此同时，我们也要评估并利用本身公司为硬件设计的嵌入式软件自带的各种特性，例如直接使用其定义的寄存器访问方式并引进到验证测试当中以避免重复定义。
　　定义通用APIs
　　话虽如此，能够为不同的测试实现提供共用组件肯定会带来更积极的作用，这其中第一步就是设计通用的API。
　　task mem2mem（
　　int unsigned channel，
　　int unsigned src，
　　int unsigned dst，
　　int unsigned sz）;
　　init_single_transfer（channel， src， 1， dst， 1， sz）;
　　wait_complete_irq（channel）;
　　endtask
　　图十 – 通用DMA API示例
　　上图的实例代码是通过对于IP层级的SV task的复用定义的一个DMA数据操作API。
　　而图十一则是相同功能在嵌入式软件当中的C代码实现。需要注意的是C代码实现当中的devid变量是由于其本身并不是面向对象的程序语言导致的。在SV环境中，mem2mem task是作为一个类的成员，在这个类的定义里devid会由PSS模型当中其他合适的对象代码所提供。但是由于C语言中并没有相关特性，用户需要提供这个变量以便于和其他模型进行通信。保持功能上一致的API能够非常显著的简化将PSS移植到不同测试解决方案的工作量，即使在实现细节上由于不同语言会有些许不同之处。
　　void wb_dma_dev_mem2mem（
　　uint32_t devid，
　　uint32_t channel，
　　uint32_t src，
　　uint32_t dst，
　　uint32_t sz，
　　uint32_t trn_sz） {
　　wb_dma_dev_t *drv = （wb_dma_dev_t *）uex_get_device（devid）;
　　uint32_t csr， sz_v;
　　uex_info_low（0， “--》 wb_dma_dev_mem2mem %s channel=%d src=0x%08x dst=0x%08x sz=%d”，
　　drv-》base.name， channel， src， dst， sz）;
　　// Disable the channel
　　csr = uex_ioread32（&drv-》regs-》channels［channel］.csr）;
　　csr &= ~（1）;
　　uex_iowrite32（csr， &drv-》regs-》channels［channel］.csr）;
　　// Program channel registers
　　csr = uex_ioread32（&drv-》regs-》channels［channel］.csr）;
　　图十一 – 通用DMA API C语言示例
　　如果垂直复用在项目中更为重要，那可考虑投入资源开发一个提升环境兼容性的中间件。比如图十二所示的UEX硬件访问层。UEX硬件访问层［2］能够提供以C为主的API来访问平台内存和多线程操作。使用这种中间件能够使得测试实现代码可以在嵌入式软件环境中开发并且可以在项目初期就可以进行debug调试，也可以在接下来多个验证环境中复用。
　　
　　图十二 – UEX硬件访问层
　　无论是否使用上述的访问兼容层，还是通过一系列API来提供这种支持，我们都需要考虑到不同IP的测试实现将如何配合。所有IP组件的测试实现代码可能都需要访问内存，而且绝大部分的IP都需要在中断发生时得到系统通知。在实际生产环境中，我们会通过操作系统来协调不同驱动同时工作。但是在验证环境中，不论是UVM还是嵌入式软件，我们都需要一个更为轻量化的解决方案。
　　static void wb_dma_dev_irq（struct uex_dev_s *devh） {
　　wb_dma_dev_t *dev = （wb_dma_dev_t *）devh;
　　uint32_t i;
　　uint32_t src_a;
　　src_a = uex_ioread32（&dev-》regs-》int_src_a）;
　　// Need to spin through the channels to determine
　　// which channel to activate
　　for （i=0; i《8; i++） {
　　if （src_a & （1 《《 i）） {
　　// Read the CSR to clear the interrupt
　　uint32_t csr = uex_ioread32（&dev-》regs-》channels［i］.csr）;
　　dev-》status［i］ = 0;
　　uex_event_signal（&dev-》xfer_ev［i］）;
　　}
　　}
　　}
　　图十三 – DMA IRQ Routine（通过UEX API 实现）
　　上图展示了DMA IP可以通过使用UEX API实现中断服务，读取DMA寄存器并在DMA传输完成之后发出通知。UEX组件库能够提供相同功能的代码，运行在UVM、或者嵌入式裸金属环境下，当然在操作系统下也能够运行。这种复用方式能够确保在项目早期即可对IP进行debug调试。