关于芯片验证的一些感悟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中, 完成数据的比对。

 

关于芯片验证的一些感悟1_第1张图片

你可能感兴趣的:(关于芯片验证的一些感悟1)