日志

一种测试激励从IP到SoC的的复用方法

已有 1526 次阅读| 2016-9-11 16:36 |个人分类:验证前沿资讯

本篇文章主要讨论如何把IP模块层面的UVM sequence复用到主要用C实现测试激励的SoC级别去，继续发挥验证作用，主要通过以下几个方面来阐述：

实现复用主要面临的挑战分析
怎么实现C和UVM共存环境的搭建
如何实现寄存器测试激励的复用
如何实现中断测试激励的复用

一、面临挑战分析

我们主要解决的第一个关键问题是如何保证我们把C的BFM(bus function model)改成UVM的总线模型时不用去更改我们的C测试激励(目的是为了能够跑UVM的sequence)，由于顶层的SOC验证工程师一般对UVM比较陌生，而且我们的总线模型随着项目更迭可能会发生变化，所以我们最好能在C的测试激励和UVM的总线模型中插入一层API，第二个需要解决的问题是如何实现没有任何改动的IP级别UVM的sequence到SOC级别的复用，解决这个问题之前我们主要先确定我们可能会复用的测试激励，由于IP和SOC是两个不同的验证级别，验证倾向是不同的，IP倾向于验证功能正确性，而SoC倾向于验证连接正确性，在这里我们讨论IP级别的寄存器测试和中断测试在SoC级别的复用，而对于实现没有任何更改的复用我们用UVM的寄存器模型和总线适配器(bus adapter)实现，第三个需要解决的问题是如何保证C和UVM之间的同步问题，从系统层面来看，C和UVM处于不同进程中，C以main()开始和结束，而UVM则是通过run_test()控制开始，由object drop来控制结束，在这里我们用最简单的同步方法，C来负责测试激励的结束，每一个C的测试激励都会在UVM的run阶段被转化为UVM的sequence，C的测试激励运行结束那么仿真就结束，而如果IP级别的UVM sequence结束，那么它会和C交互，提醒C来结束仿真。

二、SoC C-UVM环境的实现

我们的测试平台建立了一个三层的验证环境，顶层是应用层，用C来实现测试激励，中间层是事务层，由UVM的sequence来实现测试激励，底层是总线层，传输信号层面的数据，具体如下图

事务层中的PCIE_TLM2 API中有一个虚函数send(*pcie pkt)，它负责从应用层拿到数据然后发送到总线层，然后总线层的PCIE BFM接收数据后把它驱动到设计模块中，在这里我们需要把它用UVM的组件iUVC(interface UVC)替换掉，我们引进TLM2来实现send的功能，这样便于我们以后扩展，在改变后的结构中我们并不直接把PCIe的数据包转化为总线协议的数据包，而是把PCIe的数据包转化为TLM2格式的数据包，然后利用TLM2的扩展来支持不同的总线协议，这样当总线协议改变时，我们只需要更新TLM2的扩展包，数据从PCIe到TLM2的转化部分则保持不变，下面是我们改变后的数据流图和部分代码片段


除了有send函数外还有一个receive函数，它负责处理从UVM 总线层获得的反馈信号，UVM的总线层被C和UVM的测试激励共用，它可以从IP的验证环境中拿来复用，下图是一个典型的UVC的框架图
为了能够最大程度的降低维护成本，我们推荐用Systemverilog中的bind的方法和虚拟接口把IP设计和iUVC连接起来，bind的方法可以直接从IP层面复用至SOC层面，具体如下图
三、寄存器测试激励的复用
寄存器和存储器的访问测试在IP和SOC层面都主要进行验证，然而要把所有的IP寄存器测试的激励都进行复用是非常困难的，因为IP层面的端口总线协议和SOC层面的端口总线协议是不同的，而UVM的sequence通常用'uvm_do()和seq.start()来发送，而一旦总线协议发生改变，那么UVM的sequence将不能正常工作，然而RAL sequence工作在一个更高的抽象层它不受物理接口协议的影响，它只产生一般的uvm_reg_bus_op，具体转化物理总线协议的事情由后面的adapter来完成，具体如下图
上图中的adapter和address map是我们从IP到SoC复用时最关键的部分，SOC top block会例化IP层面的寄存器模型，产生一个SOC top的address map，IP层面的address map会被加在顶层的SOC top map中，adapter负责把RAL的sequence uvm_reg_bus_op转化为符合总线协议的数据包，当RAL的sequence从IP层面复用到SOC层面时，如果总线协议没有变，那么adapter和接口UVC可以直接复用，而如果总线协议有变化，那么IP adapter和接口UVC需要被SOC a
dapter和接口UVC替换，另外由于IP层面和SOC层面寄存器模型的接口不一样，为了能够最大程度减少代码修改，我们建议对于寄存器读写用一下方式来实现
四、中断测试激励的复用
首先，在这里我们的中断验证目标是：当中断发生时，可以被检测到，并且相应的中断状态寄存器的状态可以正确变化，当中断结束时，中断状态寄存器能够被清零
在进行一次仿真的时候，可能存在多个中断，每个中断都会有一个唯一的中断码来标识，中断服务程序会根据中断码来改变相应的状态寄存器并且处理中断，本文用一个中断句柄处理程序来实现，它包含一个UVM监视器，UVM的全局数据库，和一些可以复用的中断服务sequence，结构如下图：
在上图中，UVM的全局数据库是静态的，它存储了中断的入口和各个中断码的分配，可以被监视器和中断服务程序访问，当监视器检测到有中断发生时，会出发write函数把中断入口和中断码写进UVM的全局数据库，一旦中断服务程序检测到UVM全局数据库中的中断入口和中断码，就会触发wait_modified()函数，执行中断服务程序，更改相应寄存器的状态，下图是一些实现的代码片段:
当IP层面的中断测试激励被复用到SOC层面时，我们需要改变中断句柄处理程序中的监测器，把它改成SOC的中断检测器，剩下的UVM全局数据库和中断服务程序则无需改变，这样就实现了中断测试激励的复用，改变之后的结构如下图:
总结:
本文在一个三层的SOC验证环境结构(bus layer    transaction layer  和application layer)的基础上，介绍了如何把IP层面的各种测试激励复用到SOC层面去，C和UVM的测试激励如何共同工作在一个验证环境中，共用相同的总线协议模型，以及怎么实现对于寄存器访问和中断测试程序的复用机制，这使得我们垂直方向上的验证变得更加方便