APB Timer验证环境搭建——学习笔记（8）

参考模型（scoreboard）实现

1、subscribe实现

        subscribe负责监听monitor中的数据，所以先把subscribe的imp接口与monitor的port接口连接（一对多）；通过触发event的方式通知subscribe相应的事务；当monitor监测到总线上有寄存器操作，会将相应的信息广播给subscribe，subscribe可以通过get_reg_by_offset(tr.addr)（寄存器模型map的方法）得到此次操作中寄存器的句柄r，随后通过r.get_name()方法来定位某个具体的寄存器，同时trigger对应uvm_event事件，最终通过rgm.REG.get()方法拿到DUT侧寄存器配置。

        首先在 subscribe中定义好一些可能被触发的event，通过do_event_trigger方法获得目前访问寄存器的类型和具体操作，并在此声明触发这些event的条件，比如CTRL.ENBLE拉高时，则触发enable_trigger，表示目前访问的是CTRL寄存器，依次类推；

 2、scoreboard实现

       scoreboard的功能主要是模拟Timer中的counter行为以及功能检查。 scoreboard监测到数据后会做一个预测，即reference mode。一般来说scoreboard和coverage model都要继承subscribe，所以monitor也会通知scoreboard，scoreboard会拿到寄存器当前的操作，继而模拟DUT counter的行为，比如怎么能知道counter什么时候开始计数的呢？如果subscribe中触发的timer_enable的话，scoreboard也会监听和trigger，如果触发了，此时enable 置为1.counter开始工作；另外，scoreboard还需要模拟reload重新加载、interrupt的拉高和清除、counter复位等功能；

3、运行各个test，实现scoreboard       

对rkv_timer_reload_and_interrupt_test测试发现，scb与DUT counter的counting功能完美同步； 

减到1后，interrupt正常拉高，scb和DUT中的counter正常重新加载reload；目前只尝试一个test运行，后面需要根据不同test，完善scoreboard；

覆盖率收集

1、定义覆盖组

 

 2、对各个覆盖组进行采样

 3、查看覆盖率

代码覆盖率，发现存在一些行覆盖率中有3条default默认值没有覆盖到；

功能覆盖率，覆盖组t2-t5的覆盖率达到100%，但是覆盖组t1存在部分的bins没有覆盖到；

 同时，断言覆盖率也存在部分没有覆盖到的情况；

         分析某个信号跳转没有覆盖到的原因，因为为了等待寄存器模型数据的更新，发送完数据后等待了一段时间，而就在这个时间端中，某个信号的bit又被新的信号覆盖，导致收集不到某个bit的跳转，后面通过Mirror动作去监测，只要某个信号的bit位发生过这个动作，就会被自动收集，t1的覆盖率明显提高。