关于芯片验证的一些感悟1

 

 18年下半年参与了某款5G芯片验证的开发过程，空余时间总结一下：

   由于现在芯片的规模越来越大， 所以导致芯片验证的工作也越来越重要。 传统的通过写TB 的方式来测试芯片设计功能的方式也越来越吃力，而通过UVM的方式来进行芯片验证已经成为业界主流的验证方式。

    使用UVM的方式可以编写任意多个test case  配合对应的 sequence ，加上shell 脚本的辅助，可以在线切换任意的phase场景进行测试，增加了验证的自动化和灵活性，功能覆盖性也大大增强。

 

1. UVM 验证平台的搭建。

      一个UVM 验证仿真平台的搭建 ，需要一个整体的tb顶层来进行DUT 的封装，时钟和复位的激励生成，以及数据的DUMP 操作，应用的 virtual interface (VIF)  和 总线接口（AXI）的构建和初始化，以及和DUT的接口连接。  

      接下来编写各个应用场景对应的sequence  和test case ， 通过   UVM的机制来进行指定test case 的仿真运行和测试。

  sequence 主要负责 参数的随机化生成，寄存器值的初始化， 以及仿真的运行时间控制； test case 主要负责 UVM  ENV  component的初始化，以及在 main phase 中 通过对应的 sequence 来手动开启（关闭） 整个UVM平台的运行（采用 raise objection的方式）。  这里可以采用基类构建框架， 继承类 实现具体动作的方式来增加灵活性。 我们这里还在sequence body 里面，调用了refer-C DPI  的功能，来运行C 功能。

    env component 模块主要负责各个子component（agent , moniter ,scoreborad ）的集成， 这里我们使用了AXI 总线，所以这里我们也集成了AXI的一些模块（register model , adapter , VIP ）

    agent  component 集成了sequencer 和 driver 组件 ， sequencer模块功能比较简单，负责将sequence 里面的transcation形式的数据发送给 driver ； driver组件总要负责将transcation形式的数据解析给 virtual  interface  ,进而传输给了DUT 。

      moniter 组件负责将DUT 的输出打包成transaction的形式，传送给scoreboard 组件。

      scoreboard组件负责 将DUT 的数据存储到queue中，同时将refer-C 输出存储到queue中， 完成数据的比对。