SV搭建验证环境

1)首先定义纯虚类Sv_object，主要实现下边两个function：

定义local static 变量nextobjectID;

虚方法 virtual function void copy(St_object that, CloneType clone_type = DEEP);在基类中复制都可以通过super.copy来迭代copy。

2)在Sv_object的基础上，实现对mailbox和event的封装。产生两个基类Sv_mailbox_wrapper与Sv_event_wrapper。其中event多用在进程的控制

      (wait(event), event(trigger)等形式放在function内)，mailbox主要用在transaction的传递。

3)在Sv_object的基础上，建立一个Sv_testobject的纯虚类，来作为验证环境中各个组件的基类，在该基类中实现4个funciton，start,stop,main,reset。利用

      event将这几个funciton联系起来。这样便有了一个基本的控制流程。

4)Transaction类的建立，这个类不算验证环境中的构件，所以用Sv_object来extends。不过同样要在Sv_transaction这个类中建立基本的流程，比如：

      generate,execute,check。分别作用在generator段，driver, monitor,DUT段，check段。同样通过event来实现，可以实现三个function来控制这

      三个event，在上层调用实现callback。这都是针对一个tranaction来说的流程。

5)Generator基类的建立，在Sv_testobject的基础上extends，要重新定义一个generate的function，来让testcase中的generator来重定义，完成randomized

      和一些例外的constrain，或其他的回调函数。

6)Driver基类的建立，在Sv_testobject的基础上extends，因为需要加入额外额reset信号，所以在Sv_testobject的基础上，加入另外两个优先级更高的

      function，这里的优先级也就是通过event阻塞来实现的，wait_for_reset, reset。

7)Monitor基类的建立，在Sv_testobject的基础上extends，主要是在Sv_testobject的基础上定义一个receive_trans的function，来接收从DUT发出的信号。

8)Check基类的建立，在Sv_testobject的基础上extends，这个类与具体的test相关较大，基类中只需定义一些event来表示start和done。

9)Test基类的建立，在Sv_testobject的基础上extends，这个类主要是完成流程的控制，可以分为GenConfig(), ConfigDut, Build(), start(), stop, report,

      总体先配置好环境，在配置DUT，而后clock, reset, 信号进来完成初始化，而后start验证平台的各个模块开始工作，在这个阶段再根据Transaction的三个

      function来细分控制。

10)test_trans类的建立，在Transaction的基础上extends，主要是针对一些DUT中的信号的randmize定义和constrain，还需要建立一个param_trans的

      function，主要是传递transaction，这样可以在最顶层直接例化function之后将相应的mailbox联系起来。

11)test_generator类的建立，在Generator基类的基础上extends，主要是重定义generator这个function，也就是完成randomized和一些例外的constrain，或

      其他的回调函数。同样建立一个param_trans的function，接收来自test_trans的transaction。顶层例化，mailbox连接。

12)test_driver类的建立，在Driver基类的基础上extends，主要加入reset的控制，重定义driver基类中的wait_for_reset和reset这两个function。同样建立一个

      param_trans的function，接收来自test_generator的transaction和clk, reset, DUT的interface虚接口。顶层例化，mailbox连接。

13)test_Monitor基类的建立，在Monitor基类的基础上extends，主要是收集DUT的部分信号。同样建立一个param_trans的function，可以将收集到的信号组成

      一个transaction发送给test_check，还可以引入一些clk, reset的interface虚接口。顶层例化，mailbox连接。

14)test_check类的建立，在check基类的基础上extends，定义一些很细节的function，来根据收到的transaction与预想的行为进行比对。同样建立param_trans

      的function，来接受Monitor发来的transaction。顶层例化，mailbox连接。

15)testcase类的建立，在test基类的基础上extends，主要是配置验证环境，重定义GenConfig(), ConfigDut这两个function，并且在build这个function中，例化

      各个组件的param_trans这个function，来将各个mailbox连接起来。

16)定义一个Testbench_top的module，主要例化 DUT_module, DUT_if, clk_if, reset_if等RTL文件。

16)定义一个program，例化 testcase.sv, top。在initial中通过调用一个testcase中的GenConfig()来开始，整个环境开始执行。

 

最后还需要加入cover_file.sv和assert_file.sv，这两个文件不需要很复杂的继承，直接按testcase定义就好，一般还需要相应的interface信号，来与DUT进行连

    接。cover_file_if, assert_file_if。直接通过bind top绑定到顶层就好。需要修改覆盖率和SVA的时候可以直接修改，他们不影响整个验证环境。

额外定义reset和clock的模块，放在module中。它们的cover_file和assert_file，也最好单独验证。 

DUT中register的值得获取，通过Apb总线，在Driver中进行配置。

register值得获得,可以通过monitor来得到，其中test_regif是通过bind   xxxx  来定位到DUT中寄存器所在的那一级module 。

 

当然这只是一些最基本的模块，还有log文件在这个环境中怎么设计，脚本的问题等。

 

在SV中通过DPI来介入C/C++的函数，

声明：import “DPI-C” function int factorial(input bit i)

program automatic test;

initial begin

                for(int i=1; i<=10; i++)

                        $display("%0d = %0d", i, factorial(i));

         end

endprogram

input表示从SV到C，还支持output/inout，但是不支持ref。

对于C++的引用，SV只支持静态的方法，所以不能调用class 例化的对象中的function

转载于:https://www.cnblogs.com/-9-8/p/4428986.html